Date   

experimental/meta-tpm replaced by experimental/meta-trusted

Michael Halstead
 

The public git repository experimental/meta-tpm has been replaced with
experimental/meta-trusted which will include libraries and tools that
are not necessarily TCG/TPM destined as well as the work that was
already in place.

Find the new repository at
http://git.yoctoproject.org/cgit/cgit.cgi/experimental/meta-trusted/

--
Michael Halstead
Yocto Project / Sys Admin


Re: Recipe differences between Danny and Master

Ross Burton <ross.burton@...>
 

On Monday, 17 December 2012 at 20:41, Jim Abernathy wrote:
I have not tested this back on Danny, but it seems to be past the point
where it couldn't find anything. I have no idea how it worked in the
past. I remember having to toy with it a lot. I'm still not clear about
all the paths in a recipe. So I just copy others and try things that
eventually work.
The basic rule is that for a file: uri in a SRC_URI field, relative to the .bb it searches $PN-PV, $PN, then files/.

Obviously there are complications with extending that search path, and .bbappends extending the search path, but that's the underlying principle.

The practical result of this is that you can split general, per-package, and per-version files, which is useful when for example you need different patches per version of a package, but all versions can share an initscript.

Ross


Re: Recipe differences between Danny and Master

Jim Abernathy
 

On 12/17/2012 12:55 PM, Burton, Ross wrote:
On 17 December 2012 17:45, Jim Abernathy <jfabernathy@...> wrote:
SRC_URI = "file://myaudios-1.0/myaudios-1.0.tar.gz"
You don't need to specify the myaudios-1.0 section, that's implicit in
the search paths along with the unversioned ${BPN} and files/.
SRC_URI="file://myaudios-1.0.tar.gz" will find it and also work with
every previous Yocto release.

This must have worked previously because the search path logic was
rather overcomplicated and unpredictable. It was recently cleaned up
but obviously you were unknowingly relying on undocumented behaviour.
I have not tested this back on Danny, but it seems to be past the point where it couldn't find anything. I have no idea how it worked in the past. I remember having to toy with it a lot. I'm still not clear about all the paths in a recipe. So I just copy others and try things that eventually work.

Thanks,

Jim A


Ross


Re: Bug Trend ww50

Serban, Laurentiu <laurentiu.serban@...>
 

I updated the excel.

 

 

Br,
Laurentiu

 

From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Serban, Laurentiu
Sent: Monday, December 17, 2012 10:10 PM
To: yocto@...
Subject: [yocto] Bug Trend ww50

 

Hello,

 

The Yocto Project bug trend was updated for ww50.

https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend

Best regards,

 

Laurentiu Serban

QA Engineer

Open Source Technology Center

System Software Division Romania

Desk: +40 31 8604742

iNET: 88451042

 


Bug Trend ww50

Serban, Laurentiu <laurentiu.serban@...>
 

Hello,

 

The Yocto Project bug trend was updated for ww50.

https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend

Best regards,

 

Laurentiu Serban

QA Engineer

Open Source Technology Center

System Software Division Romania

Desk: +40 31 8604742

iNET: 88451042

 


ERROR: locale-base-tt-ru is listed in PACKAGES multiple times, this leads to packaging errors.

Elvis Dowson
 

Hi,
While attempting to maintain the gcc-4.5.4 and eglibc-2.13 recipes, against the current poky master, I ran into the following errors, while running bitbake meta-toolchain:

ERROR: locale-base-tt-ru is listed in PACKAGES multiple times, this leads to packaging errors.

How can I fix this error?

Best regards,

Elvis Dowson


Error: nativesdk-qemu-helper_1.0.bb, do_compile, for gcc-4.5.4 and eglibc-2.13 port against current poky master

Elvis Dowson
 

Hi,
While attempting to maintain the gcc-4.5.4 and eglibc-2.13 recipes, against the current poky master, I ran into the following errors, while running bitbake meta-toolchain:

ERROR: Function failed: do_compile (see /tool/yocto/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu-helper/1.0-r9/temp/log.do_compile.16700 for further information)
ERROR: Logfile of failure stored in: /tool/yocto/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu-helper/1.0-r9/temp/log.do_compile.16700
Log data follows:
| DEBUG: Executing shell function do_compile
| tunctl.c:5:19: fatal error: stdio.h: No such file or directory
| compilation terminated.
| ERROR: Function failed: do_compile (see /tool/yocto/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu-helper/1.0-r9/temp/log.do_compile.16700 for further information)
ERROR: Task 590 (/tool/yocto/poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb, do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1196 tasks of which 1190 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
/tool/yocto/poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb, do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

How can I fix this error?

Best regards,

Elvis Dowson


Re: Recipe differences between Danny and Master

Burton, Ross <ross.burton@...>
 

On 17 December 2012 17:45, Jim Abernathy <jfabernathy@...> wrote:
SRC_URI = "file://myaudios-1.0/myaudios-1.0.tar.gz"
You don't need to specify the myaudios-1.0 section, that's implicit in
the search paths along with the unversioned ${BPN} and files/.
SRC_URI="file://myaudios-1.0.tar.gz" will find it and also work with
every previous Yocto release.

This must have worked previously because the search path logic was
rather overcomplicated and unpredictable. It was recently cleaned up
but obviously you were unknowingly relying on undocumented behaviour.

Ross


[PATCH 5/5] scripts/lib/bsp/engine.py: refactor bsp-creation code

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

This does a bit of refactoring of the bsp-generation code to make it
generically reusable for generating non-bsp layers.

The first user remains the existing yocto-bsp tool; these changes
allow a second user, the new yocto-layer tool, to use the same code.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
scripts/lib/bsp/engine.py | 120 +++++++++++++++++++++++++---------------------
1 file changed, 65 insertions(+), 55 deletions(-)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index d406e79..6a13a03 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1039,7 +1039,9 @@ def gen_program_machine_lines(machine, program_lines):
Use the input values we got from the command line.
"""
line = "machine = \"" + machine + "\""
+ program_lines.append(line)

+ line = "layer_name = \"" + machine + "\""
program_lines.append(line)


@@ -1321,10 +1323,13 @@ def capture_context(context):
return captured_context


-def expand_targets(context, bsp_output_dir):
+def expand_targets(context, bsp_output_dir, expand_common=True):
"""
Expand all the tags in both the common and machine-specific
'targets'.
+
+ If expand_common is False, don't expand the common target (this
+ option is used to create special-purpose layers).
"""
target_files = []

@@ -1336,8 +1341,9 @@ def expand_targets(context, bsp_output_dir):
bsp_path = lib_path + '/bsp'
arch_path = bsp_path + '/substrate/target/arch'

- common = os.path.join(arch_path, "common")
- expand_target(common, target_files, bsp_output_dir)
+ if expand_common:
+ common = os.path.join(arch_path, "common")
+ expand_target(common, target_files, bsp_output_dir)

arches = os.listdir(arch_path)
if arch not in arches or arch == "common":
@@ -1352,18 +1358,17 @@ def expand_targets(context, bsp_output_dir):
return target_files


-def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, properties_file):
+def yocto_common_create(machine, arch, scripts_path, bsp_output_dir, codedump, properties_file, expand_common=True):
"""
- Create yocto layer
+ Create bsp

- layer_name - user-defined layer name
+ machine - user-defined machine name
+ arch - the arch the bsp will be based on, must be one in
+ scripts/lib/bsp/substrate/target/arch
scripts_path - absolute path to yocto /scripts dir
bsp_output_dir - dirname to create for BSP
codedump - dump generated code to bspgen.out
properties_file - use values from here if nonempty i.e no prompting
-
- arch - the arch for a generic layer is 'generic-layer', defined in
- scripts/lib/bsp/substrate/target/generic-layer
"""
if os.path.exists(bsp_output_dir):
print "\nBSP output dir already exists, exiting. (%s)" % bsp_output_dir
@@ -1383,7 +1388,7 @@ def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, pro
os.mkdir(bsp_output_dir)

context = create_context(machine, arch, scripts_path)
- target_files = expand_targets(context, bsp_output_dir)
+ target_files = expand_targets(context, bsp_output_dir, expand_common)

input_lines = gather_inputlines(target_files)

@@ -1405,7 +1410,24 @@ def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, pro

run_program_lines(program_lines, codedump)

- print "New %s BSP created in %s" % (arch, bsp_output_dir)
+
+def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, properties_file):
+ """
+ Create yocto layer
+
+ layer_name - user-defined layer name
+ scripts_path - absolute path to yocto /scripts dir
+ bsp_output_dir - dirname to create for BSP
+ codedump - dump generated code to bspgen.out
+ properties_file - use values from here if nonempty i.e no prompting
+
+ arch - the arch for a generic layer is 'generic-layer', defined in
+ scripts/lib/bsp/substrate/target/generic-layer
+ """
+ yocto_common_create(layer_name, "layer", scripts_path, layer_output_dir, codedump, properties_file, False)
+
+ print "\nNew layer created in %s.\n" % (layer_output_dir)
+ print "Don't forget to add it to your BBLAYERS (for details see %s\README)." % (layer_output_dir)


def yocto_bsp_create(machine, arch, scripts_path, bsp_output_dir, codedump, properties_file):
@@ -1420,47 +1442,9 @@ def yocto_bsp_create(machine, arch, scripts_path, bsp_output_dir, codedump, prop
codedump - dump generated code to bspgen.out
properties_file - use values from here if nonempty i.e no prompting
"""
- if os.path.exists(bsp_output_dir):
- print "\nBSP output dir already exists, exiting. (%s)" % bsp_output_dir
- sys.exit(1)
-
- properties = None
-
- if properties_file:
- try:
- infile = open(properties_file, "r")
- except IOError:
- print "Couldn't open properties file %s for reading, exiting" % properties_file
- sys.exit(1)
-
- properties = json.load(infile)
+ yocto_common_create(machine, arch, scripts_path, bsp_output_dir, codedump, properties_file)

- os.mkdir(bsp_output_dir)
-
- context = create_context(machine, arch, scripts_path)
- target_files = expand_targets(context, bsp_output_dir)
-
- input_lines = gather_inputlines(target_files)
-
- program_lines = []
-
- gen_program_header_lines(program_lines)
-
- gen_initial_property_vals(input_lines, program_lines)
-
- if properties:
- gen_supplied_property_vals(properties, program_lines)
-
- gen_program_machine_lines(machine, program_lines)
-
- if not properties:
- gen_program_input_lines(input_lines, program_lines, context)
-
- gen_program_lines(target_files, program_lines)
-
- run_program_lines(program_lines, codedump)
-
- print "New %s BSP created in %s" % (arch, bsp_output_dir)
+ print "\nNew %s BSP created in %s" % (arch, bsp_output_dir)


def print_dict(items, indent = 0):
@@ -1508,7 +1492,7 @@ def get_properties(input_lines):
return properties


-def yocto_bsp_list_properties(arch, scripts_path, properties_file):
+def yocto_bsp_list_properties(arch, scripts_path, properties_file, expand_common=True):
"""
List the complete set of properties for all the input items in the
BSP. If properties_file is non-null, write the complete set of
@@ -1516,7 +1500,7 @@ def yocto_bsp_list_properties(arch, scripts_path, properties_file):
nested dictionary.
"""
context = create_context("unused", arch, scripts_path)
- target_files = expand_targets(context, "unused")
+ target_files = expand_targets(context, "unused", expand_common)

input_lines = gather_inputlines(target_files)

@@ -1605,7 +1589,7 @@ def print_values(type, values_list):
print "[\"%s\", \"%s\"]" % (value[0], value[1])


-def yocto_bsp_list_property_values(arch, property, scripts_path, properties_file):
+def yocto_bsp_list_property_values(arch, property, scripts_path, properties_file, expand_common=True):
"""
List the possible values for a given input property. If
properties_file is non-null, write the complete set of properties
@@ -1614,7 +1598,7 @@ def yocto_bsp_list_property_values(arch, property, scripts_path, properties_file
context = create_context("unused", arch, scripts_path)
context["name"] = property

- target_files = expand_targets(context, "unused")
+ target_files = expand_targets(context, "unused", expand_common)

input_lines = gather_inputlines(target_files)

@@ -1710,6 +1694,32 @@ def yocto_bsp_list(args, scripts_path, properties_file):
return True


+def yocto_layer_list(args, scripts_path, properties_file):
+ """
+ Print the complete list of input properties defined by the layer,
+ or the possible values for a particular layer property.
+ """
+ if len(args) < 1:
+ return False
+
+ if len(args) < 1 or len(args) > 2:
+ return False
+
+ if len(args) == 1:
+ if args[0] == "properties":
+ yocto_bsp_list_properties("layer", scripts_path, properties_file, False)
+ else:
+ return False
+
+ if len(args) == 2:
+ if args[0] == "property":
+ yocto_bsp_list_property_values("layer", args[1], scripts_path, properties_file, False)
+ else:
+ return False
+
+ return True
+
+
def map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch):
"""
Return the linux-yocto bsp branch to use with the specified
--
1.7.11.4


[PATCH 4/5] yocto-layer: add 'layer' template data

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Add a 'layer' target containing all the data that will be used to
generate a generic yocto layer.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
.../bsp/substrate/target/arch/layer/COPYING.MIT | 17 ++++++
scripts/lib/bsp/substrate/target/arch/layer/README | 64 ++++++++++++++++++++++
.../substrate/target/arch/layer/conf/layer.conf | 10 ++++
.../target/arch/layer/layer-questions.noinstall | 14 +++++
.../example.patch" | 12 ++++
..._name}}_{{=example_bbappend_version}}.bbappend" | 8 +++
.../{{=example_recipe_name}}-0.1/example.patch" | 12 ++++
.../{{=example_recipe_name}}-0.1/helloworld.c" | 6 ++
.../example/{{=example_recipe_name}}_0.1.bb" | 23 ++++++++
9 files changed, 166 insertions(+)
create mode 100644 scripts/lib/bsp/substrate/target/arch/layer/COPYING.MIT
create mode 100644 scripts/lib/bsp/substrate/target/arch/layer/README
create mode 100644 scripts/lib/bsp/substrate/target/arch/layer/conf/layer.conf
create mode 100644 scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}-{{=example_bbappend_version}}/example.patch"
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}_{{=example_bbappend_version}}.bbappend"
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/example.patch"
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/helloworld.c"
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}_0.1.bb"

diff --git a/scripts/lib/bsp/substrate/target/arch/layer/COPYING.MIT b/scripts/lib/bsp/substrate/target/arch/layer/COPYING.MIT
new file mode 100644
index 0000000..89de354
--- /dev/null
+++ b/scripts/lib/bsp/substrate/target/arch/layer/COPYING.MIT
@@ -0,0 +1,17 @@
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
diff --git a/scripts/lib/bsp/substrate/target/arch/layer/README b/scripts/lib/bsp/substrate/target/arch/layer/README
new file mode 100644
index 0000000..943dfc4
--- /dev/null
+++ b/scripts/lib/bsp/substrate/target/arch/layer/README
@@ -0,0 +1,64 @@
+This README file contains information on the contents of the
+{{=layer_name}} layer.
+
+Please see the corresponding sections below for details.
+
+
+Dependencies
+============
+
+This layer depends on:
+
+ URI: git://git.openembedded.org/bitbake
+ branch: master
+
+ URI: git://git.openembedded.org/openembedded-core
+ layers: meta
+ branch: master
+
+ URI: git://git.yoctoproject.org/xxxx
+ layers: xxxx
+ branch: master
+
+
+Patches
+=======
+
+Please submit any patches against the {{=layer_name}} layer to the
+xxxx mailing list (xxxx@...) and cc: the maintainer:
+
+Maintainer: XXX YYYYYY <xxx.yyyyyy@...>
+
+
+Table of Contents
+=================
+
+ I. Adding the {{=layer_name}} layer to your build
+ II. Misc
+
+
+I. Adding the {{=layer_name}} layer to your build
+=================================================
+
+--- replace with specific instructions for the {{=layer_name}} layer ---
+
+In order to use this layer, you need to make the build system aware of
+it.
+
+Assuming the {{=layer_name}} layer exists at the top-level of your
+yocto build tree, you can add it to the build system by adding the
+location of the {{=layer_name}} layer to bblayers.conf, along with any
+other layers needed. e.g.:
+
+ BBLAYERS ?= " \
+ /path/to/yocto/meta \
+ /path/to/yocto/meta-yocto \
+ /path/to/yocto/meta-yocto-bsp \
+ /path/to/yocto/meta-{{=layer_name}} \
+ "
+
+
+II. Misc
+========
+
+--- replace with specific information about the {{=layer_name}} layer ---
diff --git a/scripts/lib/bsp/substrate/target/arch/layer/conf/layer.conf b/scripts/lib/bsp/substrate/target/arch/layer/conf/layer.conf
new file mode 100644
index 0000000..84a9abb
--- /dev/null
+++ b/scripts/lib/bsp/substrate/target/arch/layer/conf/layer.conf
@@ -0,0 +1,10 @@
+# We have a conf and classes directory, add to BBPATH
+BBPATH := "${BBPATH}:${LAYERDIR}"
+
+# We have a recipes directory, add to BBFILES
+BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+ ${LAYERDIR}/recipes-*/*/*.bbappend"
+
+BBFILE_COLLECTIONS += "{{=layer_name}}"
+BBFILE_PATTERN_{{=layer_name}} := "^${LAYERDIR}/"
+BBFILE_PRIORITY_{{=layer_name}} = "{{=layer_priority}}"
diff --git a/scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall b/scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
new file mode 100644
index 0000000..e2a89c3
--- /dev/null
+++ b/scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
@@ -0,0 +1,14 @@
+{{ input type:"edit" name:"layer_priority" prio:"20" msg:"Please enter the layer priority you'd like to use for the layer:" default:"6"}}
+
+{{ input type:"boolean" name:"create_example_recipe" prio:"20" msg:"Would you like to have an example recipe created? (y/n)" default:"n"}}
+
+{{ if create_example_recipe == "y": }}
+{{ input type:"edit" name:"example_recipe_name" prio:"20" msg:"Please enter the name you'd like to use for your example recipe:" default:"example"}}
+
+{{ input type:"boolean" name:"create_example_bbappend" prio:"20" msg:"Would you like to have an example bbappend file created? (y/n)" default:"n"}}
+
+{{ if create_example_bbappend == "y": }}
+{{ input type:"edit" name:"example_bbappend_name" prio:"20" msg:"Please enter the name you'd like to use for your bbappend file:" default:"example"}}
+
+{{ if create_example_bbappend == "y": }}
+{{ input type:"edit" name:"example_bbappend_version" prio:"20" msg:"Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to):" default:"0.1"}}
diff --git "a/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}-{{=example_bbappend_version}}/example.patch" "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}-{{=example_bbappend_version}}/example.patch"
new file mode 100644
index 0000000..2000a34
--- /dev/null
+++ "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}-{{=example_bbappend_version}}/example.patch"
@@ -0,0 +1,12 @@
+#
+# This is a non-functional placeholder file, here for example purposes
+# only.
+#
+# If you had a patch for your recipe, you'd put it in this directory
+# and reference it from your recipe's SRC_URI:
+#
+# SRC_URI += "file://example.patch"
+#
+# Note that you could also rename the directory containing this patch
+# to remove the version number or simply rename it 'files'. Doing so
+# allows you to use the same directory for multiple recipes.
diff --git "a/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}_{{=example_bbappend_version}}.bbappend" "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}_{{=example_bbappend_version}}.bbappend"
new file mode 100644
index 0000000..2e50ff6
--- /dev/null
+++ "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}_{{=example_bbappend_version}}.bbappend"
@@ -0,0 +1,8 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
+
+#
+# This .bbappend doesn't yet do anything - replace this text with
+# modifications to the example_0.1.bb recipe, or whatever recipe it is
+# that you want to modify with this .bbappend (make sure you change
+# the recipe name (PN) and version (PV) to match).
+#
diff --git "a/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/example.patch" "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/example.patch"
new file mode 100644
index 0000000..2000a34
--- /dev/null
+++ "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/example.patch"
@@ -0,0 +1,12 @@
+#
+# This is a non-functional placeholder file, here for example purposes
+# only.
+#
+# If you had a patch for your recipe, you'd put it in this directory
+# and reference it from your recipe's SRC_URI:
+#
+# SRC_URI += "file://example.patch"
+#
+# Note that you could also rename the directory containing this patch
+# to remove the version number or simply rename it 'files'. Doing so
+# allows you to use the same directory for multiple recipes.
diff --git "a/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/helloworld.c" "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/helloworld.c"
new file mode 100644
index 0000000..90ce90e
--- /dev/null
+++ "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/helloworld.c"
@@ -0,0 +1,6 @@
+#include <stdio.h>
+
+int main(int argc, char **argv)
+{
+ printf("Hello World!\n");
+}
diff --git "a/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}_0.1.bb" "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}_0.1.bb"
new file mode 100644
index 0000000..14bf344
--- /dev/null
+++ "b/scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}_0.1.bb"
@@ -0,0 +1,23 @@
+#
+# This file was derived from the 'Hello World!' example recipe in the
+# Yocto Project Development Manual.
+#
+
+DESCRIPTION = "Simple helloworld application"
+SECTION = "examples"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+PR = "r0"
+
+SRC_URI = "file://helloworld.c"
+
+S = "${WORKDIR}"
+
+do_compile() {
+ ${CC} helloworld.c -o helloworld
+}
+
+do_install() {
+ install -d ${D}${bindir}
+ install -m 0755 helloworld ${D}${bindir}
+}
--
1.7.11.4


[PATCH 3/5] yocto-layer: add help/usage

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

This is essentially 'the documentation' for the yocto-layer tool.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
scripts/lib/bsp/help.py | 228 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 228 insertions(+)

diff --git a/scripts/lib/bsp/help.py b/scripts/lib/bsp/help.py
index 3a1f52c..eac172a 100644
--- a/scripts/lib/bsp/help.py
+++ b/scripts/lib/bsp/help.py
@@ -595,6 +595,234 @@ DESCRIPTION
"""

##
+# yocto-layer help and usage strings
+##
+
+yocto_layer_usage = """
+
+ Create a generic Yocto layer.
+
+ usage: yocto-layer [--version] [--help] COMMAND [ARGS]
+
+ Current 'yocto-layer' commands are:
+ create Create a new generic Yocto layer
+ list List available values for input options and properties
+
+ See 'yocto-layer help COMMAND' for more information on a specific command.
+"""
+
+yocto_layer_help_usage = """
+
+ usage: yocto-layer help <subcommand>
+
+ This command displays detailed help for the specified subcommand.
+"""
+
+yocto_layer_create_usage = """
+
+ Create a new generic Yocto layer
+
+ usage: yocto-layer create <layer-name> [-o <DIRNAME> | --outdir <DIRNAME>]
+ [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>]
+
+ This command creates a generic Yocto layer based on the specified
+ parameters. The new layer will be a new Yocto layer contained by
+ default within the top-level directory specified as
+ 'meta-layer-name'. The -o option can be used to place the layer in a
+ directory with a different name and location.
+
+ NOTE: Once created, you should add your new layer to your
+ bblayers.conf file in order for it to be subsequently seen and
+ modified by the yocto-kernel tool. Instructions for doing this can
+ be found in the README file generated in the layer's top-level
+ directory.
+
+ See 'yocto layer help create' for more detailed instructions.
+"""
+
+yocto_layer_create_help = """
+
+NAME
+ yocto-layer create - Create a new generic Yocto layer
+
+SYNOPSIS
+ yocto-layer create <layer-name> [-o <DIRNAME> | --outdir <DIRNAME>]
+ [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>]
+
+DESCRIPTION
+ This command creates a generic Yocto layer based on the specified
+ parameters. The new layer will be a new Yocto layer contained by
+ default within the top-level directory specified as
+ 'meta-layer-name'. The -o option can be used to place the layer
+ in a directory with a different name and location.
+
+ The layer-specific properties that define the values that will be
+ used to generate the layer can be specified on the command-line
+ using the -i option and supplying a JSON object consisting of the
+ set of name:value pairs needed by the layer.
+
+ If the -i option is not used, the user will be interactively
+ prompted for each of the required property values, which will then
+ be used as values for layer generation.
+
+ The set of properties available can be listed using the
+ 'yocto-layer list' command.
+
+ Specifying -c causes the Python code generated and executed to
+ create the layer to be dumped to the 'bspgen.out' file in the
+ current directory, and is useful for debugging.
+
+ NOTE: Once created, you should add your new layer to your
+ bblayers.conf file in order for it to be subsequently seen and
+ modified by the yocto-kernel tool. Instructions for doing this
+ can be found in the README file generated in the layer's top-level
+ directory.
+
+ For example, assuming your poky repo is at /path/to/poky, your new
+ layer is at /path/to/poky/meta-mylayer, and your build directory
+ is /path/to/build:
+
+ $ gedit /path/to/build/conf/bblayers.conf
+
+ BBLAYERS ?= " \\
+ /path/to/poky/meta \\
+ /path/to/poky/meta-yocto \\
+ /path/to/poky/meta-mylayer \\
+ "
+"""
+
+yocto_layer_list_usage = """
+
+ usage: yocto-layer list properties
+ [-o <JSON PROPERTY FILE> | --outfile <JSON PROPERTY_FILE>]
+ yocto-layer list property <xxx>
+ [-o <JSON PROPERTY FILE> | --outfile <JSON PROPERTY_FILE>]
+
+ This command enumerates the complete set of possible values for a
+ specified option or property needed by the layer creation process.
+
+ The first form enumerates all the possible properties that exist and
+ must have values specified for them in the 'yocto-layer create'
+ command.
+
+ The second form enumerates all the possible values that exist and can
+ be specified for any of the enumerable properties in the 'yocto-layer
+ create' command.
+
+ See 'yocto-layer help list' for more details.
+"""
+
+yocto_layer_list_help = """
+
+NAME
+ yocto-layer list - List available values for layer input options and properties
+
+SYNOPSIS
+ yocto-layer list properties
+ [--o <JSON PROPERTY FILE> | -outfile <JSON PROPERTY_FILE>]
+ yocto-layer list property <xxx>
+ [--o <JSON PROPERTY FILE> | -outfile <JSON PROPERTY_FILE>]
+
+DESCRIPTION
+ This command enumerates the complete set of possible values for a
+ specified option or property needed by the layer creation process.
+
+ The first form enumerates all the possible properties that exist
+ and must have values specified for them in the 'yocto-layer
+ create' command. This command is mainly meant to aid the
+ development of user interface alternatives to the default
+ text-based prompting interface. If the -o option is specified,
+ the list of properties, in addition to being displayed, will be
+ written to the specified file as a JSON object. In this case, the
+ object will consist of the set of name:value pairs corresponding
+ to the (possibly nested) dictionary of properties defined by the
+ input statements used by the BSP. Some example output for the
+ 'list properties' command:
+
+ $ yocto-layer list properties
+ "example_bbappend_name" : {
+ "default" : example
+ "msg" : Please enter the name you'd like to use for your bbappend file:
+ "type" : edit
+ "prio" : 20
+ "filename" : /home/trz/yocto/yocto-layer-dev/scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
+ }
+ "create_example_recipe" : {
+ "default" : n
+ "msg" : Would you like to have an example recipe created? (y/n)
+ "type" : boolean
+ "prio" : 20
+ "filename" : /home/trz/yocto/yocto-layer-dev/scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
+ }
+ "example_recipe_name" : {
+ "default" : example
+ "msg" : Please enter the name you'd like to use for your example recipe:
+ "type" : edit
+ "prio" : 20
+ "filename" : /home/trz/yocto/yocto-layer-dev/scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
+ }
+ "layer_priority" : {
+ "default" : 6
+ "msg" : Please enter the layer priority you'd like to use for the layer:
+ "type" : edit
+ "prio" : 20
+ "filename" : /home/trz/yocto/yocto-layer-dev/scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
+ }
+ "create_example_bbappend" : {
+ "default" : n
+ "msg" : Would you like to have an example bbappend file created? (y/n)
+ "type" : boolean
+ "prio" : 20
+ "filename" : /home/trz/yocto/yocto-layer-dev/scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
+ }
+ "example_bbappend_version" : {
+ "default" : 0.1
+ "msg" : Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to):
+ "type" : edit
+ "prio" : 20
+ "filename" : /home/trz/yocto/yocto-layer-dev/scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
+ }
+
+ Each entry in the output consists of the name of the input element
+ e.g. "layer_priority", followed by the properties defined for that
+ element enclosed in braces. This information should provide
+ sufficient information to create a complete user interface. Two
+ features of the scheme provide for conditional input. First, if a
+ Python "if" statement appears in place of an input element name,
+ the set of enclosed input elements apply and should be presented
+ to the user only if the 'if' statement evaluates to true. The
+ test in the if statement will always reference another input
+ element in the list, which means that the element being tested
+ should be presented to the user before the elements enclosed by
+ the if block. Secondly, in a similar way, some elements contain
+ "depends-on" and depends-on-val" tags, which mean that the
+ affected input element should only be presented to the user if the
+ element it depends on has already been presented to the user and
+ the user has selected the specified value for that element.
+
+ The second form enumerates all the possible values that exist and
+ can be specified for any of the enumerable properties in the
+ 'yocto-layer create' command. If the -o option is specified, the
+ list of values for the given property, in addition to being
+ displayed, will be written to the specified file as a JSON object.
+ In this case, the object will consist of the set of name:value
+ pairs corresponding to the array of property values associated
+ with the property.
+
+ $ yocto-layer list property layer_priority
+ [no output - layer_priority is a text field that has no enumerable values]
+
+ The second form as well is meant mainly for developers of
+ alternative interfaces - it allows the developer to fetch the
+ possible values for a given input element on-demand. This
+ on-demand capability is especially valuable for elements that
+ require relatively expensive remote operations to fulfill, such as
+ the example that returns the set of branches available in a remote
+ git tree above.
+
+"""
+
+##
# test code
##

--
1.7.11.4


[PATCH 0/5] RFC: new 'yocto-layer' tool for creating generic Yocto layers

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Since I've been doing kind of similar work lately for the 'custom kernel'
support for yocto-bsp and have gotten several requests lately (mainly
from Darren in support of the new kernel documentation) for something
like this, I decided to just go ahead and try to quickly implement a
general-purpose layer-generation tool based on the BSP-generation code
used in the yocto-bsp tool.

There's actually an enhancement request bug for this already in the
Yocto bugzilla, but it doesn't contain many details:

Bug 3094 - Add a layer generation tool:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=3094

So anyway, this is my initial take on what that bug means. It's an RFC for
a couple reasons, first that I'd like to get comments on whether this is
actually what's needed for a 'layer generation tool', and second, because I
still need to do some cleanup of the refactored code, but don't want to
waste much time on it if it's not really what's needed.

Below are a couple examples of how it's used - you really have to try it
yourself to see what's generated - I don't want to post tarballs or such on
the list and it's simple to generate and look at the layers.

The first case is just a very simple layer with a layer.conf and README -
basically the simplest layer you can create, and which exists mainly because
even that is easy to get wrong. As with the yocto-bsp tool, the script
queries the user for a couple items, here we just take the defaults, which
are a priority of 6 for the layer and no other components such as example
recipes:

[trz@empanada build]$ yocto-layer create simplestlayer
Please enter the layer priority you'd like to use for the layer: [default: 6]
Would you like to have an example recipe created? (y/n) [default: n]
Would you like to have an example bbappend file created? (y/n) [default: n]

New layer created in meta-simplestlayer.

Don't forget to add it to your BBLAYERS (for details see meta-simplestlayer\README).

[trz@empanada build]$ find .
.
./meta-simplestlayer
./meta-simplestlayer/conf
./meta-simplestlayer/conf/layer.conf
./meta-simplestlayer/README
./meta-simplestlayer/COPYING.MIT


In the second case, we tell the tool that we do want an example .bb and and
an example .bbappend. We're queried for the recipe name that we want our
recipe to have, and for the .bbappend, the name of the base recipe and its
version. Below you can see the files it generates - please look at the files
themselves to see the contents. For the recipe example, it generates a recipe
based on the example in the Yocto manual, and my own helloworld.c code
(untested so far which is also why this is an RFC). For the .bbappend example,
it just creates an empty .patch file with some instructions on what to do to
modify the parent recipe with a patch:

[trz@empanada build]$ yocto-layer create mylayer
Please enter the layer priority you'd like to use for the layer: [default: 6]
Would you like to have an example recipe created? (y/n) [default: n] y
Please enter the name you'd like to use for your example recipe: [default: example] flork
Would you like to have an example bbappend file created? (y/n) [default: n] y
Please enter the name you'd like to use for your bbappend file: [default: example] chork
Please enter the version number you'd like to use for your bbappend file (this should match the recipe you're appending to): [default: 0.1] 0.22.3

New layer created in meta-mylayer.

Don't forget to add it to your BBLAYERS (for details see meta-mylayer\README).

[trz@empanada build]$ find .
.
./meta-mylayer
./meta-mylayer/recipes-example
./meta-mylayer/recipes-example/example
./meta-mylayer/recipes-example/example/flork-0.1
./meta-mylayer/recipes-example/example/flork-0.1/helloworld.c
./meta-mylayer/recipes-example/example/flork-0.1/example.patch
./meta-mylayer/recipes-example/example/flork_0.1.bb
./meta-mylayer/conf
./meta-mylayer/conf/layer.conf
./meta-mylayer/recipes-example-bbappend
./meta-mylayer/recipes-example-bbappend/example-bbappend
./meta-mylayer/recipes-example-bbappend/example-bbappend/chork-0.22.3
./meta-mylayer/recipes-example-bbappend/example-bbappend/chork-0.22.3/example.patch
./meta-mylayer/recipes-example-bbappend/example-bbappend/chork_0.22.3.bbappend
./meta-mylayer/README
./meta-mylayer/COPYING.MIT

Please try it and look at the generated code - any comments or suggestions
are welcome.

Thanks,

Tom

The following changes since commit da598d4f0fcf6faa62055084a51d70d735399d33:

eglibc: fix checksums of fetched patches (2012-12-13 18:02:21 +0000)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib.git tzanussi/yocto-layer-rfc
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/yocto-layer-rfc

Tom Zanussi (5):
scripts/lib/bsp/engine.py: add yocto_layer_create()
yocto-layer: new script
yocto-layer: add help/usage
yocto-layer: add 'layer' template data
scripts/lib/bsp/engine.py: refactor bsp-creation code

scripts/lib/bsp/engine.py | 86 +++++++-
scripts/lib/bsp/help.py | 228 +++++++++++++++++++++
.../bsp/substrate/target/arch/layer/COPYING.MIT | 17 ++
scripts/lib/bsp/substrate/target/arch/layer/README | 64 ++++++
.../substrate/target/arch/layer/conf/layer.conf | 10 +
.../target/arch/layer/layer-questions.noinstall | 14 ++
.../example.patch" | 12 ++
..._name}}_{{=example_bbappend_version}}.bbappend" | 8 +
.../{{=example_recipe_name}}-0.1/example.patch" | 12 ++
.../{{=example_recipe_name}}-0.1/helloworld.c" | 6 +
.../example/{{=example_recipe_name}}_0.1.bb" | 23 +++
scripts/yocto-layer | 142 +++++++++++++
12 files changed, 612 insertions(+), 10 deletions(-)
create mode 100644 scripts/lib/bsp/substrate/target/arch/layer/COPYING.MIT
create mode 100644 scripts/lib/bsp/substrate/target/arch/layer/README
create mode 100644 scripts/lib/bsp/substrate/target/arch/layer/conf/layer.conf
create mode 100644 scripts/lib/bsp/substrate/target/arch/layer/layer-questions.noinstall
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}-{{=example_bbappend_version}}/example.patch"
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_bbappend == \"y\": }} recipes-example-bbappend/example-bbappend/{{=example_bbappend_name}}_{{=example_bbappend_version}}.bbappend"
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/example.patch"
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}-0.1/helloworld.c"
create mode 100644 "scripts/lib/bsp/substrate/target/arch/layer/{{ if create_example_recipe == \"y\": }} recipes-example/example/{{=example_recipe_name}}_0.1.bb"
create mode 100755 scripts/yocto-layer

--
1.7.11.4


[PATCH 2/5] yocto-layer: new script

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Implementation of the 'yocto-layer' command-line tool, for creating
generic layers and listing their input properties.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
scripts/yocto-layer | 142 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 142 insertions(+)
create mode 100755 scripts/yocto-layer

diff --git a/scripts/yocto-layer b/scripts/yocto-layer
new file mode 100755
index 0000000..f759275
--- /dev/null
+++ b/scripts/yocto-layer
@@ -0,0 +1,142 @@
+#!/usr/bin/env python
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+#
+# Copyright (c) 2012, Intel Corporation.
+# All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# DESCRIPTION
+# 'yocto-layer' is the Yocto Tool that helps users create a new Yocto
+# layer. Invoking it without any arguments will display help screens
+# for the 'yocto-layer' command and list the available 'yocto-layer'
+# subcommands. Invoking a subcommand without any arguments will
+# likewise display help screens for the specified subcommand. Please
+# use that interface for detailed help.
+#
+# AUTHORS
+# Tom Zanussi <tom.zanussi (at] intel.com>
+#
+
+__version__ = "0.1.0"
+
+import os
+import sys
+import optparse
+import logging
+
+scripts_path = os.path.abspath(os.path.dirname(os.path.abspath(sys.argv[0])))
+lib_path = scripts_path + '/lib'
+sys.path = sys.path + [lib_path]
+
+from bsp.help import *
+from bsp.engine import *
+
+
+def yocto_layer_create_subcommand(args, usage_str):
+ """
+ Command-line handling for layer creation. The real work is done by
+ bsp.engine.yocto_layer_create()
+ """
+ parser = optparse.OptionParser(usage = usage_str)
+
+ parser.add_option("-o", "--outdir", dest = "outdir", action = "store",
+ help = "name of layer dir to create")
+ parser.add_option("-i", "--infile", dest = "properties_file", action = "store",
+ help = "name of file containing the values for layer input properties as a JSON file")
+ parser.add_option("-c", "--codedump", dest = "codedump", action = "store_true",
+ default = False, help = "dump the generated code to layergen.out")
+ (options, args) = parser.parse_args(args)
+
+ if len(args) != 1:
+ logging.error("Wrong number of arguments, exiting\n")
+ parser.print_help()
+ sys.exit(1)
+
+ layer_name = args[0]
+
+ if options.outdir:
+ layer_output_dir = options.outdir
+ else:
+ layer_output_dir = "meta-" + layer_name
+
+ yocto_layer_create(layer_name, scripts_path, layer_output_dir, options.codedump, options.properties_file)
+
+
+def yocto_layer_list_subcommand(args, usage_str):
+ """
+ Command-line handling for listing available layer properties and
+ values. The real work is done by bsp.engine.yocto_layer_list()
+ """
+ parser = optparse.OptionParser(usage = usage_str)
+
+ parser.add_option("-o", "--outfile", action = "store", dest = "properties_file",
+ help = "dump the possible values for layer properties to a JSON file")
+
+ (options, args) = parser.parse_args(args)
+
+ if not yocto_layer_list(args, scripts_path, options.properties_file):
+ logging.error("Bad list arguments, exiting\n")
+ parser.print_help()
+ sys.exit(1)
+
+
+subcommands = {
+ "create": [yocto_layer_create_subcommand,
+ yocto_layer_create_usage,
+ yocto_layer_create_help],
+ "list": [yocto_layer_list_subcommand,
+ yocto_layer_list_usage,
+ yocto_layer_list_help],
+}
+
+
+def start_logging(loglevel):
+ logging.basicConfig(filname = 'yocto-layer.log', filemode = 'w', level=loglevel)
+
+
+def main():
+ parser = optparse.OptionParser(version = "yocto-layer version %s" % __version__,
+ usage = yocto_layer_usage)
+
+ parser.disable_interspersed_args()
+ parser.add_option("-D", "--debug", dest = "debug", action = "store_true",
+ default = False, help = "output debug information")
+
+ (options, args) = parser.parse_args()
+
+ loglevel = logging.INFO
+ if options.debug:
+ loglevel = logging.DEBUG
+ start_logging(loglevel)
+
+ if len(args):
+ if args[0] == "help":
+ if len(args) == 1:
+ parser.print_help()
+ sys.exit(1)
+
+ invoke_subcommand(args, parser, yocto_layer_help_usage, subcommands)
+
+
+if __name__ == "__main__":
+ try:
+ ret = main()
+ except Exception:
+ ret = 1
+ import traceback
+ traceback.print_exc(5)
+ sys.exit(ret)
+
--
1.7.11.4


[PATCH 1/5] scripts/lib/bsp/engine.py: add yocto_layer_create()

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Add a new yocto_layer_create() function that will be used to generate
a generic yocto layer (for the new 'yocto-layer' command).

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
scripts/lib/bsp/engine.py | 56 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 8985544..d406e79 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1352,6 +1352,62 @@ def expand_targets(context, bsp_output_dir):
return target_files


+def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, properties_file):
+ """
+ Create yocto layer
+
+ layer_name - user-defined layer name
+ scripts_path - absolute path to yocto /scripts dir
+ bsp_output_dir - dirname to create for BSP
+ codedump - dump generated code to bspgen.out
+ properties_file - use values from here if nonempty i.e no prompting
+
+ arch - the arch for a generic layer is 'generic-layer', defined in
+ scripts/lib/bsp/substrate/target/generic-layer
+ """
+ if os.path.exists(bsp_output_dir):
+ print "\nBSP output dir already exists, exiting. (%s)" % bsp_output_dir
+ sys.exit(1)
+
+ properties = None
+
+ if properties_file:
+ try:
+ infile = open(properties_file, "r")
+ except IOError:
+ print "Couldn't open properties file %s for reading, exiting" % properties_file
+ sys.exit(1)
+
+ properties = json.load(infile)
+
+ os.mkdir(bsp_output_dir)
+
+ context = create_context(machine, arch, scripts_path)
+ target_files = expand_targets(context, bsp_output_dir)
+
+ input_lines = gather_inputlines(target_files)
+
+ program_lines = []
+
+ gen_program_header_lines(program_lines)
+
+ gen_initial_property_vals(input_lines, program_lines)
+
+ if properties:
+ gen_supplied_property_vals(properties, program_lines)
+
+ gen_program_machine_lines(machine, program_lines)
+
+ if not properties:
+ gen_program_input_lines(input_lines, program_lines, context)
+
+ gen_program_lines(target_files, program_lines)
+
+ run_program_lines(program_lines, codedump)
+
+ print "New %s BSP created in %s" % (arch, bsp_output_dir)
+
+
def yocto_bsp_create(machine, arch, scripts_path, bsp_output_dir, codedump, properties_file):
"""
Create bsp
--
1.7.11.4


Recipe differences between Danny and Master

Jim Abernathy
 

I have a recipe layers I use for test videos and audios that I included in prior BSPs I've done. The last I tested it was Danny and it worked fine. Today I tried to add it to a BSP that had previously built, using the latest pull from Master, complete without errors and booted.

Once I added my layer, it built with a number of errors. So something has changed, that I missed. Below is my one of my recipes and the console log:

DESCRIPTION = "my audio test files"
SECTION = "examples"
LICENSE = "CLOSED"

MY_DESTINATION = "/home/root/myaudios"

SRC_URI = "file://myaudios-1.0/myaudios-1.0.tar.gz"

do_install_append() {
install -d ${D}${MY_DESTINATION}
install -m 0644 ${S}/* ${D}${MY_DESTINATION}
}

PR = "r0"

FILES_${PN} += "${MY_DESTINATION}/*"
----------------------------------------------------------------------------------------------

jim@jim-ubuntu-x64:/build/nuc-master$ bitbake core-image-sato
WARNING: Unable to get checksum for myvideos SRC_URI entry myvideos-1.0.tar.gz: file could not be found
WARNING: Unable to get checksum for myaudios SRC_URI entry myaudios-1.0.tar.gz: file could not be found
Parsing recipes: 100% |###################################################| Time: 00:00:11
Parsing of 842 .bb files complete (0 cached, 842 parsed). 1149 targets, 24 skipped, 0 masked, 0 errors.

Build Configuration:
BB_VERSION = "1.17.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Ubuntu-12.04"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "nuc"
DISTRO = "poky"
DISTRO_VERSION = "1.3+snapshot-20121217"
TUNE_FEATURES = "m64"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp = "master:958162e96b4a4f23bca94500b5f20975633dd5c6"
meta-intel
meta-nuc = "master:4122c514a22442a58b2f99e4ba9617ff219b3089"
meta-jfa = "<unknown>:<unknown>"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Failed to fetch URL file://myaudios-1.0/myaudios-1.0.tar.gz, attempting MIRRORS if available
WARNING: Failed to fetch URL file://myvideos-1.0/myvideos-1.0.tar.gz, attempting MIRRORS if available
ERROR: Fetcher failure: Unable to find file file://myaudios-1.0/myaudios-1.0.tar.gz anywhere. The paths that were searched were:
/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios-1.0/x86-64
/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios-1.0/nuc
/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios-1.0/poky
/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios-1.0/
/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios/x86-64
/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios/nuc
/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios/poky
/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios/
/home/jim/meta-jfa/recipes-jfa/myaudio/files/x86-64
/home/jim/meta-jfa/recipes-jfa/myaudio/files/nuc
/home/jim/meta-jfa/recipes-jfa/myaudio/files/poky
/home/jim/meta-jfa/recipes-jfa/myaudio/files/
/home/jim/yocto-downloads
ERROR: Function failed: Fetcher failure for URL: 'file://myaudios-1.0/myaudios-1.0.tar.gz'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /build/nuc-master/tmp/work/x86_64-poky-linux/myaudios/1.0-r0/temp/log.do_fetch.29282
ERROR: Fetcher failure: Unable to find file file://myvideos-1.0/myvideos-1.0.tar.gz anywhere. The paths that were searched were:
/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos-1.0/x86-64
/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos-1.0/nuc
/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos-1.0/poky
/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos-1.0/
/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos/x86-64
/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos/nuc
/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos/poky
/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos/
/home/jim/meta-jfa/recipes-jfa/myvideos/files/x86-64
/home/jim/meta-jfa/recipes-jfa/myvideos/files/nuc
/home/jim/meta-jfa/recipes-jfa/myvideos/files/poky
/home/jim/meta-jfa/recipes-jfa/myvideos/files/
/home/jim/yocto-downloads
ERROR: Function failed: Fetcher failure for URL: 'file://myvideos-1.0/myvideos-1.0.tar.gz'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /build/nuc-master/tmp/work/x86_64-poky-linux/myvideos/1.0-r0/temp/log.do_fetch.29283
ERROR: Task 353 (/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios.bb, do_fetch) failed with exit code '1'
ERROR: Task 341 (/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos.bb, do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4122 tasks of which 4109 didn't need to be rerun and 2 failed.
Waiting for 0 running tasks to finish:

Summary: 2 tasks failed:
/home/jim/meta-jfa/recipes-jfa/myaudio/myaudios.bb, do_fetch
/home/jim/meta-jfa/recipes-jfa/myvideos/myvideos.bb, do_fetch
Summary: There were 4 WARNING messages shown.
Summary: There were 4 ERROR messages shown, returni


Re: Specifying different make flags for different tasks.

Alex Gonzalez
 

Hi Chris,

Yes, that would be exactly what I want, except that it' not working for me.

Probably something obvious, but just in case, any reason why this
should not work in denzil?

Thanks,
Alex

On Mon, Dec 17, 2012 at 4:24 PM, Chris Larson <clarson@...> wrote:


On Mon, Dec 17, 2012 at 1:36 AM, Alex Gonzalez <alex@...>
wrote:

I am using EXTRA_OEMAKE to pass extra flags to make.

How can I pass different flags for different tasks?

In this case I am compiling an external kernel module and I need
different make flags for the do_make_scripts and do_compile tasks. If
I set EXTRA_OEMAKE in the recipe, all tasks use the same make flags.

You could use the task-<taskname> override. E.g.:

EXTRA_OEMAKE_append_task-do_compile = " FOO=bar"
--
Christopher Larson


Re: IMHO, cross-compile/toolchain examples should use non-x86 arches

Zhang, Jessica
 

Or in Yocto Project context, we kind of use ADT more inclusive that referring what Mark talked about SDK, the eclipse plug-in and other developers tools. And we don't call out SDK that much.

--Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Mark Hatle
Sent: Monday, December 17, 2012 7:48 AM
To: yocto@...
Subject: Re: [yocto] IMHO, cross-compile/toolchain examples should use non-x86 arches

On 12/16/12 4:57 PM, Sean Liming wrote:

My 2c (USD) is for clarity on ADT vs. SDK vs. Toolchain.
The biggest clarify problem I've seen is the terms being intermingled. There are clear definitions for each.

Toolchain, the compiler and related tools that enable compiling software for a given target.

SDK - Software Development Kit - On OE-Core this purpose of this is to enable developing software to be run on a specific target environment, generally also constructed from OE-Core. The SDK consists of three primary components:
1) environment setup files - these configure the compilation environment with the right settings
2) nativesdk software - these are applications that run on the -host- system to assist in compiling software for the target (this includes the target toolchain.)
3) target sysroot - The sysroot is the collection of libraries, headers and assorted items that are compiled for the target. A sysroot is setup in a similar fashion as a target's root filesystem.

ADT - Application Developer Tool - This is an Eclipse component that can use the SDK, generated by OE-Core, to enable application development within the Eclipse framework. (I may be slightly wrong on this item, as people have told me in the past there are command line parts to the ADT.... but the ADT itself is -not- the
SDK.)

--Mark

Regards,

Sean Liming
Owner
Annabooks
Tel: 714-970-7523 / Cell: 858-774-3176

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Robert P. J. Day
Sent: Sunday, December 16, 2012 8:55 AM
To: Yocto discussion list
Subject: [yocto] IMHO, cross-compile/toolchain examples should use
non-
x86 arches


a general preference on my part, but i think it would be useful if
any
yocto
docs that are discussing toolchains or cross-compilation or the like
use
*non*-x86 architectures to get the point across.

for example, consider the current application developer's guide.
part of it uses, as an example, the toolchain installer
poky-eglibc-x86_64-i586-
toolchain-gmae-1.4.sh. while this works just fine, of course, what
it
does is
potentially co-mingle both the dev host content and target host
content, making it harder than necessary for the reader to draw a
clear distinction between the two.

if any example related to compilation or a toolchain involves,
say, an
*arm*
target, then it's *immediately* obvious (using the "file"
command) whether something belongs on the dev host or on the target.

also, if you're using x86 for both dev content and target content,
you
run
the risk of an example working by accident since you're picking up
natively-
installed tools when you shouldn't be. if you use a non-x86 arch,
there's
little
chance of that happening.

just my $0.02 (Cdn).

rday


--

==========================================================
==============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
==========================================================
==============
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: IMHO, cross-compile/toolchain examples should use non-x86 arches

Mark Hatle <mark.hatle@...>
 

On 12/16/12 4:57 PM, Sean Liming wrote:

My 2c (USD) is for clarity on ADT vs. SDK vs. Toolchain.
The biggest clarify problem I've seen is the terms being intermingled. There are clear definitions for each.

Toolchain, the compiler and related tools that enable compiling software for a given target.

SDK - Software Development Kit - On OE-Core this purpose of this is to enable developing software to be run on a specific target environment, generally also constructed from OE-Core. The SDK consists of three primary components:
1) environment setup files - these configure the compilation environment with the right settings
2) nativesdk software - these are applications that run on the -host- system to assist in compiling software for the target (this includes the target toolchain.)
3) target sysroot - The sysroot is the collection of libraries, headers and assorted items that are compiled for the target. A sysroot is setup in a similar fashion as a target's root filesystem.

ADT - Application Developer Tool - This is an Eclipse component that can use the SDK, generated by OE-Core, to enable application development within the Eclipse framework. (I may be slightly wrong on this item, as people have told me in the past there are command line parts to the ADT.... but the ADT itself is -not- the SDK.)

--Mark

Regards,

Sean Liming
Owner
Annabooks
Tel: 714-970-7523 / Cell: 858-774-3176

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Robert P. J. Day
Sent: Sunday, December 16, 2012 8:55 AM
To: Yocto discussion list
Subject: [yocto] IMHO, cross-compile/toolchain examples should use non-
x86 arches


a general preference on my part, but i think it would be useful if any
yocto
docs that are discussing toolchains or cross-compilation or the like use
*non*-x86 architectures to get the point across.

for example, consider the current application developer's guide.
part of it uses, as an example, the toolchain installer
poky-eglibc-x86_64-i586-
toolchain-gmae-1.4.sh. while this works just fine, of course, what it
does is
potentially co-mingle both the dev host content and target host content,
making it harder than necessary for the reader to draw a clear distinction
between the two.

if any example related to compilation or a toolchain involves, say, an
*arm*
target, then it's *immediately* obvious (using the "file"
command) whether something belongs on the dev host or on the target.

also, if you're using x86 for both dev content and target content, you
run
the risk of an example working by accident since you're picking up
natively-
installed tools when you shouldn't be. if you use a non-x86 arch, there's
little
chance of that happening.

just my $0.02 (Cdn).

rday


--

==========================================================
==============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
==========================================================
==============
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: Where does the bitbake get the variable "TOPDIR"

Eren Türkay <eren@...>
 

On Mon, Dec 17, 2012 at 05:06:26PM +0800, Biao wrote:
Greetings,

I am a newbie tying to understand how bitbake works.
There is one line as BBPATH = "${TOPDIR}" in the mybuild/conf/bblayers.conf, i would like to know where the TOPDIR is defined?
It's defind in "lib/bb/parse/parse_py/ConfHandler.py:36". When TOPDIR is
not defined in any of the bitbake configuration files, it's set to
current working directory automatically.

(...)

def init(data):
topdir = data.getVar('TOPDIR')
if not topdir:
data.setVar('TOPDIR', os.getcwd())

(...)

You may want to read the newly-written documentation about bitbake and
open embedded. I tried to explain how things fit together. I would like
to have your feedback.

http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/

--
. 73! DE TA1AET
http://linkedin.com/in/erenturkay


Re: Specifying different make flags for different tasks.

Chris Larson <clarson@...>
 



On Mon, Dec 17, 2012 at 1:36 AM, Alex Gonzalez <alex@...> wrote:
I am using EXTRA_OEMAKE to pass extra flags to make.

How can I pass different flags for different tasks?

In this case I am compiling an external kernel module and I need
different make flags for the do_make_scripts and do_compile tasks. If
I set EXTRA_OEMAKE in the recipe, all tasks use the same make flags.

You could use the task-<taskname> override. E.g.:

EXTRA_OEMAKE_append_task-do_compile = " FOO=bar"
--
Christopher Larson