<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openembedded-core.git/meta/classes/cross-canadian.bbclass, branch daisy</title>
<subtitle>Mirror of openembedded-core</subtitle>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/'/>
<entry>
<title>cross-canadian: Let cross-canadian packages build for uclibc</title>
<updated>2013-11-08T17:27:14+00:00</updated>
<author>
<name>Khem Raj</name>
<email>raj.khem@gmail.com</email>
</author>
<published>2013-11-07T03:52:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=7928a9e54dfa85cbfd042e25ed883a9795f09f1b'/>
<id>7928a9e54dfa85cbfd042e25ed883a9795f09f1b</id>
<content type='text'>
Fixes errors like

Parsing recipes...ERROR: Building cross-candian powerpc for an unknown
TARGET_SYS (powerpc-angstrom-linux-uclibc), please update
cross-canadian.bbclass
ERROR: Building cross-candian powerpc for an unknown TARGET_SYS
(powerpc-angstrom-linux-uclibc), please update cross-canadian.bbclass

Signed-off-by: Khem Raj &lt;raj.khem@gmail.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes errors like

Parsing recipes...ERROR: Building cross-candian powerpc for an unknown
TARGET_SYS (powerpc-angstrom-linux-uclibc), please update
cross-canadian.bbclass
ERROR: Building cross-candian powerpc for an unknown TARGET_SYS
(powerpc-angstrom-linux-uclibc), please update cross-canadian.bbclass

Signed-off-by: Khem Raj &lt;raj.khem@gmail.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cross-canadian: Improve comment</title>
<updated>2013-10-30T18:00:56+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2013-10-17T11:35:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=154ecc40c289b15fe9cbb33befb20dd10112e788'/>
<id>154ecc40c289b15fe9cbb33befb20dd10112e788</id>
<content type='text'>
The previous cross-canadian change was missing some tweaks
to the comments. This clarifies them slightly.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The previous cross-canadian change was missing some tweaks
to the comments. This clarifies them slightly.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cross-canadian: Handle powerpc linux verses linux-gnuspe</title>
<updated>2013-10-30T17:33:00+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2013-10-17T11:22:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=a1d6331238982b0c5d39b0a18794f6654b00d46a'/>
<id>a1d6331238982b0c5d39b0a18794f6654b00d46a</id>
<content type='text'>
PowerPC toolchains can use the OS "linux" or "linux-gnuspe". This
patch links them together so the one cross-canadian toolchain can support
both.

GCC_FOR_TARGET is set for the GCC recipe as otherwise configure
can pick up an incorrect value.

[YOCTO #5354]

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PowerPC toolchains can use the OS "linux" or "linux-gnuspe". This
patch links them together so the one cross-canadian toolchain can support
both.

GCC_FOR_TARGET is set for the GCC recipe as otherwise configure
can pick up an incorrect value.

[YOCTO #5354]

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cross-canadian: Fix SHLIBSDIR when using multilib</title>
<updated>2013-10-16T12:27:56+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2013-10-15T13:40:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=0633b93086a7de7226f4dc6ca403ee116bc58669'/>
<id>0633b93086a7de7226f4dc6ca403ee116bc58669</id>
<content type='text'>
Both nativesdk and multilib use MLPREFIX for their partciular purposes. When
we have both set, cross-canadian can confuse SHLIBSDIR. This forces the
variable to the correct value for cross-canadian, fixing toolchains in
multilib builds.

[YOCTO #5333]

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Both nativesdk and multilib use MLPREFIX for their partciular purposes. When
we have both set, cross-canadian can confuse SHLIBSDIR. This forces the
variable to the correct value for cross-canadian, fixing toolchains in
multilib builds.

[YOCTO #5333]

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cross-canadian: Fix TUNE_PKGARCH references</title>
<updated>2013-10-04T17:25:06+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2013-10-02T13:09:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=f58acab6414fe96d9e07ebbe86b348d2ac2bed5f'/>
<id>f58acab6414fe96d9e07ebbe86b348d2ac2bed5f</id>
<content type='text'>
The cross-canadian compilers are now build once per architecture but were being
installed into tune specific locations which is incorrect. This adjusts things
so they are make TARGET_ARCH specific. We gain the tune specific parts from the
target sysroot which remains tune specific, the compiler and tools are independent
ot that.

binutils/gcc require sysroot options but since we reset at runtime, these shouldn't
have dependencies in the sstate checksums. They are therefore also excluded.

With these patches, switching machines does not result in a rebuild of *-cross-canadian
and the compiler is correctly located and referenced in the target images.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The cross-canadian compilers are now build once per architecture but were being
installed into tune specific locations which is incorrect. This adjusts things
so they are make TARGET_ARCH specific. We gain the tune specific parts from the
target sysroot which remains tune specific, the compiler and tools are independent
ot that.

binutils/gcc require sysroot options but since we reset at runtime, these shouldn't
have dependencies in the sstate checksums. They are therefore also excluded.

With these patches, switching machines does not result in a rebuild of *-cross-canadian
and the compiler is correctly located and referenced in the target images.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bitbake.conf/package: Collapse PKGDATA_DIR into a single machine specific directory</title>
<updated>2013-09-13T16:41:10+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2013-09-13T12:35:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=1b8e4abd2d9c0901d38d89d0f944fe1ffd019379'/>
<id>1b8e4abd2d9c0901d38d89d0f944fe1ffd019379</id>
<content type='text'>
Currently we have a hierarchy of pkgdata directories and the code has to put together
a search path and look through each in turn until it finds the data it needs.

This has lead to a number of hardcoded paths and file globing which
is unpredictable and undesirable. Worse, certain tricks that should be
easy like a GL specific package architecture become problematic with the
curretn search paths.

With the modern sstate code, we can do better and construct a single pkgdata
directory for each machine in just the same way as we do for the sysroot. This
is already tried and well tested. With such a single directory, all the code that
iterated through multiple pkgdata directories and simply be removed and give
a significant simplification of the code. Even existing build directories adapt
to the change well since the package contents doesn't change, just the location
they're installed to and the stamp for them.

The only complication is the we need a different shlibs directory for each
multilib. These are only used by package.bbclass and the simple fix is to
add MLPREFIX to the shlib directory name. This means the multilib packages will
repackage and the sstate checksum will change but an existing build directory
will adapt to the changes safely.

It is close to release however I believe the benefits this patch give us
are worth consideration for inclusion and give us more options for dealing
with problems like the GL one. It also sets the ground work well for
shlibs improvements in 1.6.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently we have a hierarchy of pkgdata directories and the code has to put together
a search path and look through each in turn until it finds the data it needs.

This has lead to a number of hardcoded paths and file globing which
is unpredictable and undesirable. Worse, certain tricks that should be
easy like a GL specific package architecture become problematic with the
curretn search paths.

With the modern sstate code, we can do better and construct a single pkgdata
directory for each machine in just the same way as we do for the sysroot. This
is already tried and well tested. With such a single directory, all the code that
iterated through multiple pkgdata directories and simply be removed and give
a significant simplification of the code. Even existing build directories adapt
to the change well since the package contents doesn't change, just the location
they're installed to and the stamp for them.

The only complication is the we need a different shlibs directory for each
multilib. These are only used by package.bbclass and the simple fix is to
add MLPREFIX to the shlib directory name. This means the multilib packages will
repackage and the sstate checksum will change but an existing build directory
will adapt to the changes safely.

It is close to release however I believe the benefits this patch give us
are worth consideration for inclusion and give us more options for dealing
with problems like the GL one. It also sets the ground work well for
shlibs improvements in 1.6.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bitbake.conf/classes/gcc: Don't hardcode -nativesdk</title>
<updated>2013-08-22T17:30:06+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2013-08-22T09:12:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=a2110e86b98d646e136de9ec6b8e668079b0d4f4'/>
<id>a2110e86b98d646e136de9ec6b8e668079b0d4f4</id>
<content type='text'>
Hardcoding -nativesdk as the sdk package architecture is inflexible. We may have
multiple different target OS and we need a way to be able to separate them. Turning
this into a configurable value allows the flexibility we need to build different
SDKMACHINEs with different OS targets.

The commit should have no behaviour change, just makes things more configurable.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Hardcoding -nativesdk as the sdk package architecture is inflexible. We may have
multiple different target OS and we need a way to be able to separate them. Turning
this into a configurable value allows the flexibility we need to build different
SDKMACHINEs with different OS targets.

The commit should have no behaviour change, just makes things more configurable.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>gettext: Improve USE_NLS handling for nativesdk/crosssdk/cross-canadian</title>
<updated>2013-08-22T17:30:05+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2013-08-20T17:13:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=fe634d47449899f7424adb77ff5bc7ddf8a07a47'/>
<id>fe634d47449899f7424adb77ff5bc7ddf8a07a47</id>
<content type='text'>
The gettext handling of USE_NLS has become a bit tricky to understand, or
alter from the SDK context. This patch introduces a SDKUSE_NLS which can
be set to configure a given SDK/ADT to use NLS or not. This is independent
of the target system NLS usage.

The code in gettext.bbclass is therefore simplified and the classes
themselves now set USE_NLS to appropriate values. No NLS is used
for native, cross and crosssdk since it is never used there and
would just increase build time.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The gettext handling of USE_NLS has become a bit tricky to understand, or
alter from the SDK context. This patch introduces a SDKUSE_NLS which can
be set to configure a given SDK/ADT to use NLS or not. This is independent
of the target system NLS usage.

The code in gettext.bbclass is therefore simplified and the classes
themselves now set USE_NLS to appropriate values. No NLS is used
for native, cross and crosssdk since it is never used there and
would just increase build time.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>classes: Drop do_package stamp-extra-info</title>
<updated>2012-11-21T16:53:56+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2012-11-20T08:13:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=1c54d8c3639659bc8cf8fa2786a1aa9ed785b723'/>
<id>1c54d8c3639659bc8cf8fa2786a1aa9ed785b723</id>
<content type='text'>
This was needed when do_package for target recipes was target specific
however since it now isn't we can remove these stale references.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This was needed when do_package for target recipes was target specific
however since it now isn't we can remove these stale references.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>package.bbclass: Switch shlibs to pkgdata directory and make package non-machine specific</title>
<updated>2012-10-22T08:46:05+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2012-10-18T23:08:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=cc088489d70fb27d460c3dbe35d6ea382123c134'/>
<id>cc088489d70fb27d460c3dbe35d6ea382123c134</id>
<content type='text'>
Currently, do_package is machine specific since the shlibs data is installed
into each machine specific sysroot. This change moves the shlibs data to the
pkgdata structure, at the expense of having to iterate over a set of shlibs
directories instead of a single one.

It turns out this isn't any particular hardship for the code and as a result,
do_package stops being machine specific leading to optimisations for builds
that use a common PACKAGE_ARCH.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, do_package is machine specific since the shlibs data is installed
into each machine specific sysroot. This change moves the shlibs data to the
pkgdata structure, at the expense of having to iterate over a set of shlibs
directories instead of a single one.

It turns out this isn't any particular hardship for the code and as a result,
do_package stops being machine specific leading to optimisations for builds
that use a common PACKAGE_ARCH.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
