[yocto] eo_filter_out not working
Hi,
I'm trying to build the packagegroup-core-p1 from the meta-ivi layer,
but I would like to remove the RRECOMMENDS as I don't want X11. To do
this, I've added a packagegroup-core-p1.bbappend to my own layer. In
this file I've tried the following options:
Attempt #1
RRECOMMENDS_packagegroup-core-p1 :=
${@oe_filter_out('packagegroup-xserver-ivi',
'${RRECOMMENDS_packagegroup-core-p1}', d)}
ERROR: ExpansionError during parsing
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-ivi/recipes-yocto-ivi/packagegroups/packagegroup-core-p1.bb:
Failure expanding variable RRECOMMENDS_packagegroup-core-p1[:=],
expression was ${@oe_filter_out('packagegroup-xserver-ivi',
'${RRECOMMENDS_packagegroup-core-p1}', d)} which triggered exception
SyntaxError: EOL while scanning string literal
(RRECOMMENDS_packagegroup-core-p1[:=], line 1)
I read this as RECOMMENDS_packagegroup-core-p1 is not yet set, so the
oe_filter_out part fails.
Attempt #2
RRECOMMENDS_packagegroup-core-p1 := foo
WARNING: Variable key RRECOMMENDS_${PN} (packagegroup-xserver-ivi
) replaces original key RRECOMMENDS_packagegroup-core-p1 (foo).
This sort of explains why attempt #1 fails, as it seems that the bb is
evaluated after the bbappend.
So this leads me to my question. Why is the bb apparently evaluated
after the bbappend? Running bitbake with -DDD does not indicate this
(see below), so I smell something fishy (or I don't fully grasp how
things are meant to work)
$ bitbake -DDD packagegroup-core-p1 | grep core-p1
DEBUG: BB
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-ivi/recipes-yocto-ivi/packagegroups/packagegroup-core-p1.bb:
handle(data)
DEBUG: LOAD
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-ivi/recipes-yocto-ivi/packagegroups/packagegroup-core-p1.bb
DEBUG: BB
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-ivi/recipes-yocto-ivi/packagegroups/packagegroup-core-p1.bb:6:
inheriting
/home/e8johan/work/yocto/pelagicore-bsp/sources/poky/meta/classes/packagegroup.bbclass
DEBUG: Appending .bbappend file
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-pelagicore/meta-pelagicore/recipes-yocto-ivi/packagegroups/packagegroup-core-p1.bbappend
to
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-ivi/recipes-yocto-ivi/packagegroups/packagegroup-core-p1.bb
DEBUG: BB
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-pelagicore/meta-pelagicore/recipes-yocto-ivi/packagegroups/packagegroup-core-p1.bbappend:
handle(data, include)
DEBUG: LOAD
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-pelagicore/meta-pelagicore/recipes-yocto-ivi/packagegroups/packagegroup-core-p1.bbappend
WARNING: Variable key RRECOMMENDS_${PN} (packagegroup-xserver-ivi
) replaces original key RRECOMMENDS_packagegroup-core-p1 (foo).
DEBUG: Cache:
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-ivi/recipes-yocto-ivi/packagegroups/packagegroup-core-p1.bb
is not cached
So, what am I doing wrong?
Best regards,
Johan Thelin ヨハン テリン
M.Sc.E.E.
System Architect
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)700 900 250
Skype: jothpelagicore
E-Mail: johan.the...@pelagicore.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] External-Sourcery-Toolchain Related Issue
Hi,
I want to install my existing Toolchain to Yocto Sysroot bypassing default
yocto toolchain functionality.
My requirements are
1I will download toolchain from my git source ie tar file.
2I just want to install this toolchain to tmp/sysroot folder in build directory
skipping compilation step.
Steps implemented
1 SRC_URI = file:///home/toolchains_bin.tarfile:///\\home\toolchains_bin.tar
2 TCMODE=external-csl
3 EXTERNAL_TOOLCHAIN =
/home/yocto/poky/build/tmp/work/mips64-poky-linux/external-sourcery-toolchain/GCC-r8/toolchains_bin/mipscross/linux
4CSL_TARGET_SYS_mips64 = ${TARGET_ARCH}${TARGET_TC_VENDOR}-${TCTYPE}
5CSL_TARGET_SYS = ${TARGET_ARCH}${TARGET_TC_VENDOR}-${TCTYPE}
6 TARGET_PREFIX = ${CSL_TARGET_SYS_mips64}-
But when I tried to run
Build bitbake linux (linux is recipe in my layer)
It gives me error :
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/home/yocto/poky/build/tmp/work/mips64-poky-linux/external-sourcery-toolchain/GCC-r8/toolchains_bin/mipscross/linux/bin/mips64-nlm-linux-gcc
-v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/home/yocto/poky/build/tmp/work/mips64-poky-linux/external-sourcery-toolchain/GCC-r8/toolchains_bin/mipscross/linux/bin/mips64-nlm-linux-gcc
-v' failed: command not found
and continue with the tasks executions like unpacking toolchains_bin.tar to
$WORKDIR/mips64-poky-linux/.. and other linux do configure etc
Again run this recipe:
@Buildbitbake linux
NOTE. Once unpacked the toolchain to the location specified if I again run the
above recipe then this error does not come.
Please suggest me the way around to skip this error coming at the first time
when I build my recipe until my toolchain is not unpacked.
Thanks in advance!
Regards,
Rohit Jindal
===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [eclipse-poky][PATCH 00/13] Completed CMake integration in the Yocto IDE
From: Atanas Gegov atanas.ge...@bmw-carit.de Hi, this patch series adds a new plugin containing a CMake configure tool, a toolchain and a project type for building CMake projects in the Yocto IDE. The plugin also introduces Hello World templates for C and C++. With this patch series the CMake integration is completed and the CMake projects can be built, debugged etc. as already known from the Autotools-based projects. Cheers, Atanas P.S: This patch series requires the already discussed patch series [eclipse-poky][RFCv2 0/7] Introducing a YoctoSDKCMakeProjectNature. Atanas Gegov (13): plugins/cmake: Added an empty CMake integration plugin plugins/cmake: Defined CMake tool with options plugins/sdk.ide: Added a method to get project environment plugins/cmake: Preparing a configure Job plugins/cmake: Added run method to configure Job plugins/cmake: Added a Makefile generator plugins/cmake: Added the generation of toolchain.cmake plugins/cmake: Defined the building toolchain plugins/cmake: Added a new category for CMake projects plugins/cmake: Connect toolchain and new project category plugins/cmake: Added CMake template projects plugins/sdk.ide: Adapted RemoteDebugLauncher for CMake projects features/sdk: Added CMake plugin to sdk feature features/org.yocto.sdk/feature.xml |6 + plugins/org.yocto.cmake.managedbuilder/.classpath |7 + plugins/org.yocto.cmake.managedbuilder/.project| 28 ++ .../.settings/org.eclipse.jdt.core.prefs |8 + .../META-INF/MANIFEST.MF | 16 ++ .../OSGI-INF/l10n/bundle.properties| 40 +++ .../build.properties |7 + plugins/org.yocto.cmake.managedbuilder/plugin.xml | 283 .../org/yocto/cmake/managedbuilder/Activator.java | 50 .../YoctoCMakeMakefileGenerator.java | 281 +++ .../cmake/managedbuilder/YoctoCMakeMessages.java | 57 .../managedbuilder/YoctoCMakeMessages.properties | 27 ++ .../managedbuilder/job/ExecuteConfigureJob.java| 149 +++ .../cmake/managedbuilder/util/ConsoleUtility.java | 49 .../cmake/managedbuilder/util/SystemProcess.java | 118 .../HelloWorldCCMakeProject/src/CMakeLists.txt | 34 +++ .../HelloWorldCCMakeProject/src/main.c | 21 ++ .../HelloWorldCCMakeProject/template.properties| 31 +++ .../HelloWorldCCMakeProject/template.xml | 61 + .../HelloWorldCPPCMakeProject/src/CMakeLists.txt | 34 +++ .../HelloWorldCPPCMakeProject/src/main.cpp | 21 ++ .../HelloWorldCPPCMakeProject/template.properties | 31 +++ .../HelloWorldCPPCMakeProject/template.xml | 61 + .../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 29 +- 24 files changed, 1445 insertions(+), 4 deletions(-) create mode 100644 plugins/org.yocto.cmake.managedbuilder/.classpath create mode 100644 plugins/org.yocto.cmake.managedbuilder/.project create mode 100644 plugins/org.yocto.cmake.managedbuilder/.settings/org.eclipse.jdt.core.prefs create mode 100644 plugins/org.yocto.cmake.managedbuilder/META-INF/MANIFEST.MF create mode 100644 plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties create mode 100644 plugins/org.yocto.cmake.managedbuilder/build.properties create mode 100644 plugins/org.yocto.cmake.managedbuilder/plugin.xml create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/Activator.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMessages.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMessages.properties create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/util/ConsoleUtility.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/util/SystemProcess.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/CMakeLists.txt create mode 100644 plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/main.c create mode 100644 plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/template.properties create mode 100644 plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/template.xml create mode 100644 plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCPPCMakeProject/src/CMakeLists.txt create mode 100644
[yocto] [PATCH 01/13] plugins/cmake: Added an empty CMake integration plugin
From: Atanas Gegov atanas.ge...@bmw-carit.de This plugin will implement the CMake managed builder (CMake toolchain for Eclipse) and will also provide CMake template projects. --- plugins/org.yocto.cmake.managedbuilder/.classpath |7 +++ plugins/org.yocto.cmake.managedbuilder/.project| 28 ++ .../.settings/org.eclipse.jdt.core.prefs |8 +++ .../META-INF/MANIFEST.MF | 16 ++ .../OSGI-INF/l10n/bundle.properties| 13 + .../build.properties |6 +++ plugins/org.yocto.cmake.managedbuilder/plugin.xml |4 ++ .../org/yocto/cmake/managedbuilder/Activator.java | 50 + .../cmake/managedbuilder/YoctoCMakeMessages.java | 57 9 files changed, 189 insertions(+) create mode 100644 plugins/org.yocto.cmake.managedbuilder/.classpath create mode 100644 plugins/org.yocto.cmake.managedbuilder/.project create mode 100644 plugins/org.yocto.cmake.managedbuilder/.settings/org.eclipse.jdt.core.prefs create mode 100644 plugins/org.yocto.cmake.managedbuilder/META-INF/MANIFEST.MF create mode 100644 plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties create mode 100644 plugins/org.yocto.cmake.managedbuilder/build.properties create mode 100644 plugins/org.yocto.cmake.managedbuilder/plugin.xml create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/Activator.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMessages.java diff --git a/plugins/org.yocto.cmake.managedbuilder/.classpath b/plugins/org.yocto.cmake.managedbuilder/.classpath new file mode 100644 index 000..ad32c83 --- /dev/null +++ b/plugins/org.yocto.cmake.managedbuilder/.classpath @@ -0,0 +1,7 @@ +?xml version=1.0 encoding=UTF-8? +classpath + classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6/ + classpathentry kind=con path=org.eclipse.pde.core.requiredPlugins/ + classpathentry kind=src path=src/ + classpathentry kind=output path=bin/ +/classpath diff --git a/plugins/org.yocto.cmake.managedbuilder/.project b/plugins/org.yocto.cmake.managedbuilder/.project new file mode 100644 index 000..67c7f68 --- /dev/null +++ b/plugins/org.yocto.cmake.managedbuilder/.project @@ -0,0 +1,28 @@ +?xml version=1.0 encoding=UTF-8? +projectDescription + nameorg.yocto.cmake.managedbuilder/name + comment/comment + projects + /projects + buildSpec + buildCommand + nameorg.eclipse.jdt.core.javabuilder/name + arguments + /arguments + /buildCommand + buildCommand + nameorg.eclipse.pde.ManifestBuilder/name + arguments + /arguments + /buildCommand + buildCommand + nameorg.eclipse.pde.SchemaBuilder/name + arguments + /arguments + /buildCommand + /buildSpec + natures + natureorg.eclipse.pde.PluginNature/nature + natureorg.eclipse.jdt.core.javanature/nature + /natures +/projectDescription diff --git a/plugins/org.yocto.cmake.managedbuilder/.settings/org.eclipse.jdt.core.prefs b/plugins/org.yocto.cmake.managedbuilder/.settings/org.eclipse.jdt.core.prefs new file mode 100644 index 000..c1a4ce9 --- /dev/null +++ b/plugins/org.yocto.cmake.managedbuilder/.settings/org.eclipse.jdt.core.prefs @@ -0,0 +1,8 @@ +#Wed Jul 14 11:43:59 CEST 2010 +eclipse.preferences.version=1 +org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled +org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.6 +org.eclipse.jdt.core.compiler.compliance=1.6 +org.eclipse.jdt.core.compiler.problem.assertIdentifier=error +org.eclipse.jdt.core.compiler.problem.enumIdentifier=error +org.eclipse.jdt.core.compiler.source=1.6 diff --git a/plugins/org.yocto.cmake.managedbuilder/META-INF/MANIFEST.MF b/plugins/org.yocto.cmake.managedbuilder/META-INF/MANIFEST.MF new file mode 100644 index 000..2ed5451 --- /dev/null +++ b/plugins/org.yocto.cmake.managedbuilder/META-INF/MANIFEST.MF @@ -0,0 +1,16 @@ +Manifest-Version: 1.0 +Bundle-ManifestVersion: 2 +Bundle-Name: %Bundle-Name +Bundle-SymbolicName: org.yocto.cmake.managedbuilder;singleton:=true +Bundle-Version: 1.4.0.qualifier +Bundle-Activator: org.yocto.cmake.managedbuilder.Activator +Bundle-Vendor: %Bundle-Vendor +Require-Bundle: org.eclipse.cdt.managedbuilder.core, + org.eclipse.cdt.core;bundle-version=5.2.1, + org.eclipse.core.resources;bundle-version=3.6.0, + org.eclipse.core.runtime;bundle-version=3.6.0, + org.eclipse.ui.console;bundle-version=3.5.0, + org.eclipse.ui;bundle-version=3.6.2, + org.yocto.sdk.ide
[yocto] [PATCH 02/13] plugins/cmake: Defined CMake tool with options
From: Atanas Gegov atanas.ge...@bmw-carit.de
Defined a tool using the cmake command with some
options and a free text-field for custom options.
This tool will become part of the builder
toolchain for building CMake projects.
---
.../OSGI-INF/l10n/bundle.properties| 14 +++
plugins/org.yocto.cmake.managedbuilder/plugin.xml | 102
2 files changed, 116 insertions(+)
diff --git
a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
index 86125e4..ff9b374 100644
--- a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
+++ b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
@@ -11,3 +11,17 @@
Bundle-Vendor = yoctoproject.org
Bundle-Name = Yocto CMake Plugin
+
+# Extension name
+extension.name=Yocto CMake Managed Builder
+
+# CMake configure
+cmakeconfigure.name=CMake configure
+cmakeconfigure.options=CMake Options
+cmakeconfigure.sourcepath=Relative source path
+cmakeconfigure.toolchaincmakefilepath=Relative toolchain.cmake path
+cmakeconfigure.debugsymbols=Compile with debug symbols
+cmakeconfigure.verbosemakefile=Generate verbose Makefiles
+cmakeconfigure.wdev=Enable developer warnings (-Wdev)
+cmakeconfigure.wnodev=Suppress developer warnings (-Wno-dev)
+cmakeconfigure.otherflags=Other flags
diff --git a/plugins/org.yocto.cmake.managedbuilder/plugin.xml
b/plugins/org.yocto.cmake.managedbuilder/plugin.xml
index f422d55..5b56628 100644
--- a/plugins/org.yocto.cmake.managedbuilder/plugin.xml
+++ b/plugins/org.yocto.cmake.managedbuilder/plugin.xml
@@ -1,4 +1,106 @@
?xml version=1.0 encoding=UTF-8?
?eclipse version=3.4?
plugin
+extension
+id=org.yocto.cmake.managedbuilder
+name=%extension.name
+point=org.eclipse.cdt.managedbuilder.core.buildDefinitions
+managedBuildRevision
+fileVersion=4.0.0
+/managedBuildRevision
+tool
+id=org.yocto.cmake.managedbuilder.cmakeconfigure
+name=%cmakeconfigure.name
+command=cmake
+commandLinePattern=${COMMAND} ${FLAGS}
+natureFilter=both
+optionCategory
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.category.options
+name=%cmakeconfigure.options
+/optionCategory
+option
+
category=org.yocto.cmake.managedbuilder.cmakeconfigure.category.options
+defaultValue=${OECMAKE_SOURCEPATH}
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.sourcepath
+isAbstract=false
+name=%cmakeconfigure.sourcepath
+resourceFilter=all
+valueType=string
+/option
+option
+
category=org.yocto.cmake.managedbuilder.cmakeconfigure.category.options
+
defaultValue=-DCMAKE_TOOLCHAIN_FILE=${OECMAKE_SOURCEPATH}/toolchain.cmake
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.toolchaincmakefilepath
+isAbstract=false
+name=%cmakeconfigure.toolchaincmakefilepath
+resourceFilter=all
+valueType=string
+/option
+option
+
category=org.yocto.cmake.managedbuilder.cmakeconfigure.category.options
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.debugsymbols
+name=%cmakeconfigure.debugsymbols
+isAbstract=false
+resourceFilter=all
+valueType=enumerated
+enumeratedOptionValue
+command=-DCMAKE_BUILD_TYPE=DEBUG
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.debugsymbols.eOV1
+isDefault=true
+name=Yes (-DCMAKE_BUILD_TYPE=DEBUG)
+/enumeratedOptionValue
+enumeratedOptionValue
+command=
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.debugsymbols.eOV2
+name=No
+/enumeratedOptionValue
+/option
+option
+
category=org.yocto.cmake.managedbuilder.cmakeconfigure.category.options
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.verbosemakefile
+name=%cmakeconfigure.verbosemakefile
+isAbstract=false
+resourceFilter=all
+valueType=enumerated
+enumeratedOptionValue
+command=-DCMAKE_VERBOSE_MAKEFILE=1
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.verbosemakefile.eOV1
+isDefault=true
+name=Yes (-DCMAKE_VERBOSE_MAKEFILE=1)
+/enumeratedOptionValue
+enumeratedOptionValue
+
[yocto] [PATCH 03/13] plugins/sdk.ide: Added a method to get project environment
From: Atanas Gegov atanas.ge...@bmw-carit.de
This methods creates a key-value map from the
project environment. It can be used to provide
this environment to new processes.
---
.../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 16
1 file changed, 16 insertions(+)
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
index f27fad7..669157b 100644
--- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
@@ -8,6 +8,7 @@
* Contributors:
* Intel - initial API and implementation
* BMW Car IT - add methods to use different preference stores
+ * Atanas Gegov (BMW Car IT) - add method to get the project environment
***/
package org.yocto.sdk.ide.utils;
@@ -87,6 +88,21 @@ public class YoctoSDKUtils {
return var.getValue();
}
+ public static MapString,String getEnvVariablesAsMap (IProject
project) {
+ MapString, String result = new HashMapString, String();
+
+ ICProjectDescription cpdesc =
CoreModel.getDefault().getProjectDescription(project, true);
+ ICConfigurationDescription ccdesc =
cpdesc.getActiveConfiguration();
+ IEnvironmentVariableManager manager =
CCorePlugin.getDefault().getBuildEnvironmentManager();
+ IContributedEnvironment env =
manager.getContributedEnvironment();
+
+ for(IEnvironmentVariable var : env.getVariables(ccdesc)) {
+ result.put(var.getName(), var.getValue());
+ }
+
+ return result;
+ }
+
/* Save project wide settings into ENV VARs including POKY preference
settings
* and Environment Script File export VARs
*/
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 04/13] plugins/cmake: Preparing a configure Job
From: Atanas Gegov atanas.ge...@bmw-carit.de
This job will execute the configure step for the
CMake projects. It uses the command defined by the
CMake tool (cmake) and gets the provided options
from the user to assemble the command line.
---
.../managedbuilder/YoctoCMakeMessages.properties | 18 +++
.../managedbuilder/job/ExecuteConfigureJob.java| 124
.../cmake/managedbuilder/util/SystemProcess.java | 118 +++
3 files changed, 260 insertions(+)
create mode 100644
plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMessages.properties
create mode 100644
plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java
create mode 100644
plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/util/SystemProcess.java
diff --git
a/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMessages.properties
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMessages.properties
new file mode 100644
index 000..ac5dad8
--- /dev/null
+++
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMessages.properties
@@ -0,0 +1,18 @@
+#/***
+# * Copyright (c) 2013 BMW Car IT GmbH.
+# * All rights reserved. This program and the accompanying materials
+# * are made available under the terms of the Eclipse Public License v1.0
+# * which accompanies this distribution, and is available at
+# * http://www.eclipse.org/legal/epl-v10.html
+# *
+# * Contributors:
+# * BMW Car IT - initial implementation
+#
***/
+
+# Job
+ExecuteConfigureJob.runConfigure=Running configure
+ExecuteConfigureJob.consoleName=Configure using CMake [{0}]
+ExecuteConfigureJob.buildingMakefile=Building Makefile
+ExecuteConfigureJob.warning.aborted=Build of project has been aborted
+ExecuteConfigureJob.error.couldNotStart=Build of project could not be started
+ExecuteConfigureJob.error.buildFailed=Build of project failed
diff --git
a/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java
new file mode 100644
index 000..ebed4bb
--- /dev/null
+++
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java
@@ -0,0 +1,124 @@
+/***
+ * Copyright (c) 2013 BMW Car IT GmbH.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * BMW Car IT - initial API and implementation
+
***/
+package org.yocto.cmake.managedbuilder.job;
+
+import java.io.IOException;
+import java.util.Arrays;
+import java.util.LinkedList;
+
+import org.eclipse.cdt.managedbuilder.core.BuildException;
+import org.eclipse.cdt.managedbuilder.core.IConfiguration;
+import org.eclipse.cdt.managedbuilder.core.ITool;
+import org.eclipse.core.resources.IProject;
+import org.eclipse.core.runtime.IPath;
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.core.runtime.IStatus;
+import org.eclipse.core.runtime.Status;
+import org.eclipse.core.runtime.jobs.Job;
+import org.eclipse.ui.console.IOConsoleOutputStream;
+import org.yocto.cmake.managedbuilder.Activator;
+import org.yocto.cmake.managedbuilder.YoctoCMakeMessages;
+import org.yocto.cmake.managedbuilder.util.ConsoleUtility;
+import org.yocto.cmake.managedbuilder.util.SystemProcess;
+import org.yocto.sdk.ide.utils.YoctoSDKUtils;
+
+
+public class ExecuteConfigureJob extends Job {
+ private SystemProcess configureProcess;
+ private LinkedListString configureCommand;
+ private IProject project;
+ private IConfiguration configuration;
+ private IPath location;
+
+
+ public ExecuteConfigureJob(String name,
+ IProject project, IConfiguration configuration, IPath
location) {
+ super(name);
+ this.project = project;
+ this.configuration = configuration;
+ this.location = location;
+ createCommands();
+ createProcesses();
+ }
+
+ protected void createCommands() {
+ configureCommand = new LinkedListString();
+
+ ITool[] configure = configuration
+
.getToolsBySuperClassId(org.yocto.cmake.managedbuilder.cmakeconfigure.gnu.exe);
//$NON-NLS-1$
+
+
[yocto] [PATCH 05/13] plugins/cmake: Added run method to configure Job
From: Atanas Gegov atanas.ge...@bmw-carit.de
The job executes the configure step of the project
using the cmake command. The output is
presented in a new console.
---
.../managedbuilder/job/ExecuteConfigureJob.java| 25 ++
.../cmake/managedbuilder/util/ConsoleUtility.java | 49
2 files changed, 74 insertions(+)
create mode 100644
plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/util/ConsoleUtility.java
diff --git
a/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java
index ebed4bb..29e708e 100644
---
a/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java
+++
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java
@@ -92,6 +92,31 @@ public class ExecuteConfigureJob extends Job {
*/
@Override
protected IStatus run(IProgressMonitor monitor) {
+ monitor.beginTask(
+
YoctoCMakeMessages.getString(ExecuteConfigureJob.runConfigure), 20);
//$NON-NLS-1$
+
+ IOConsoleOutputStream cos =
+
ConsoleUtility.getConsoleOutput(YoctoCMakeMessages.getFormattedString(ExecuteConfigureJob.consoleName,
//$NON-NLS-1$
+ project.getName()));
+ monitor.worked(1);
+
+ try {
+ return buildProject(monitor, cos);
+ } catch (IOException e) {
+ return new Status(Status.ERROR,
+ Activator.PLUGIN_ID, Status.OK,
+
YoctoCMakeMessages.getString(ExecuteConfigureJob.error.couldNotStart), e);
//$NON-NLS-1$
+ } catch (InterruptedException e) {
+ return new Status(Status.WARNING,
+ Activator.PLUGIN_ID,
+
YoctoCMakeMessages.getString(ExecuteConfigureJob.warning.aborted));
//$NON-NLS-1$
+ } finally {
+ try {
+ cos.close();
+ } catch (IOException e) {
+ cos = null;
+ }
+ }
}
private IStatus buildProject(IProgressMonitor monitor,
diff --git
a/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/util/ConsoleUtility.java
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/util/ConsoleUtility.java
new file mode 100644
index 000..9fb31e5
--- /dev/null
+++
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/util/ConsoleUtility.java
@@ -0,0 +1,49 @@
+/***
+ * Copyright (c) 2013 BMW Car IT GmbH.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * BMW Car IT - initial API and implementation
+
***/
+package org.yocto.cmake.managedbuilder.util;
+
+import org.eclipse.ui.console.ConsolePlugin;
+import org.eclipse.ui.console.IConsole;
+import org.eclipse.ui.console.IOConsoleOutputStream;
+import org.eclipse.ui.console.MessageConsole;
+
+
+public class ConsoleUtility {
+
+ public static IOConsoleOutputStream getConsoleOutput(String
consoleName) {
+ return getConsole(consoleName).newOutputStream();
+ }
+
+ public static MessageConsole getConsole(String consoleName) {
+ MessageConsole foundConsole = findConsole(consoleName);
+ if (foundConsole != null) {
+ foundConsole.clearConsole();
+ } else {
+ foundConsole = new MessageConsole(consoleName, null);
+ ConsolePlugin.getDefault().
+ getConsoleManager().addConsoles(new IConsole[] {
foundConsole });
+ }
+
+ return foundConsole;
+ }
+
+ public static MessageConsole findConsole(String consoleName) {
+ IConsole[] consoles =
+
ConsolePlugin.getDefault().getConsoleManager().getConsoles();
+ for (IConsole console : consoles) {
+ if (console.getName().equals(consoleName)) {
+ return (MessageConsole) console;
+ }
+ }
+
+ return null;
+ }
+}
--
1.7.9.5
[yocto] [PATCH 06/13] plugins/cmake: Added a Makefile generator
From: Atanas Gegov atanas.ge...@bmw-carit.de
Defined a ManagedBuilder and a corresponding
Makefile generator class. In order to create
Makefiles the cmake configure job is run. By now
it is assumed that the required toolchain.cmake
file is provided by the user. The next patch adds
the toolchain.cmake generation.
---
.../OSGI-INF/l10n/bundle.properties|3 +
plugins/org.yocto.cmake.managedbuilder/plugin.xml |9 +
.../YoctoCMakeMakefileGenerator.java | 174
.../managedbuilder/YoctoCMakeMessages.properties |9 +
4 files changed, 195 insertions(+)
create mode 100644
plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java
diff --git
a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
index ff9b374..c66fcb9 100644
--- a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
+++ b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
@@ -15,6 +15,9 @@ Bundle-Name = Yocto CMake Plugin
# Extension name
extension.name=Yocto CMake Managed Builder
+# Builder
+builder.name=Yocto CMake Environment Builder
+
# CMake configure
cmakeconfigure.name=CMake configure
cmakeconfigure.options=CMake Options
diff --git a/plugins/org.yocto.cmake.managedbuilder/plugin.xml
b/plugins/org.yocto.cmake.managedbuilder/plugin.xml
index 5b56628..e8faadd 100644
--- a/plugins/org.yocto.cmake.managedbuilder/plugin.xml
+++ b/plugins/org.yocto.cmake.managedbuilder/plugin.xml
@@ -8,6 +8,15 @@
managedBuildRevision
fileVersion=4.0.0
/managedBuildRevision
+builder
+id=org.yocto.cmake.managedbuilder.builder
+name=%builder.name
+
buildfileGenerator=org.yocto.cmake.managedbuilder.YoctoCMakeMakefileGenerator
+cleanBuildTarget=clean
+command=make
+isVariableCaseSensitive=false
+supportsManagedBuild=true
+/builder
tool
id=org.yocto.cmake.managedbuilder.cmakeconfigure
name=%cmakeconfigure.name
diff --git
a/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java
new file mode 100644
index 000..d80f603
--- /dev/null
+++
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java
@@ -0,0 +1,174 @@
+/***
+ * Copyright (c) 2013 BMW Car IT GmbH.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * BMW Car IT - initial API and implementation
+
***/
+package org.yocto.cmake.managedbuilder;
+
+import java.io.ByteArrayInputStream;
+import java.io.InputStream;
+
+import org.eclipse.cdt.managedbuilder.core.IBuilder;
+import org.eclipse.cdt.managedbuilder.core.IConfiguration;
+import org.eclipse.cdt.managedbuilder.core.IManagedBuildInfo;
+import org.eclipse.cdt.managedbuilder.core.ManagedBuildManager;
+import org.eclipse.cdt.managedbuilder.core.ManagedBuilderCorePlugin;
+import
org.eclipse.cdt.managedbuilder.makegen.IManagedBuilderMakefileGenerator2;
+import org.eclipse.core.resources.IFile;
+import org.eclipse.core.resources.IProject;
+import org.eclipse.core.resources.IResource;
+import org.eclipse.core.resources.IResourceDelta;
+import org.eclipse.core.runtime.CoreException;
+import org.eclipse.core.runtime.IPath;
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.core.runtime.IStatus;
+import org.eclipse.core.runtime.MultiStatus;
+import org.eclipse.core.runtime.jobs.Job;
+import org.yocto.cmake.managedbuilder.job.ExecuteConfigureJob;
+import org.yocto.sdk.ide.utils.YoctoSDKUtils;
+
+public class YoctoCMakeMakefileGenerator implements
IManagedBuilderMakefileGenerator2 {
+
+ private static final String TOOLCHAINCMAKE_FILE_NAME =
toolchain.cmake; //$NON-NLS-1$
+ private static final String MAKEFILE_NAME = Makefile; //$NON-NLS-1$
+ private static final String CMAKE_FILE_NAME = CMakeLists.txt;
//$NON-NLS-1$
+ private static final String CMAKECACHE_FILE_NAME = CMakeCache.txt;
//$NON-NLS-1$
+
+ private IProject project;
+ private int lastBuildInfoChecksum = 0;
+ private IConfiguration configuration;
+ private IProgressMonitor monitor;
+ private IPath buildDir = null;
+
+ @Override
+ public String getMakefileName() {
+ return MAKEFILE_NAME;
+ }
+
+ @Override
[yocto] [PATCH 07/13] plugins/cmake: Added the generation of toolchain.cmake
From: Atanas Gegov atanas.ge...@bmw-carit.de
The generation of the toolchain.cmake file happens
just before the exectuion of the configure job.
The current environment of the project is used to
set the values in the toolchain.cmake file.
---
.../YoctoCMakeMakefileGenerator.java | 107
1 file changed, 107 insertions(+)
diff --git
a/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java
index d80f603..b77ae9e 100644
---
a/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java
+++
b/plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java
@@ -149,6 +149,8 @@ public class YoctoCMakeMakefileGenerator implements
IManagedBuilderMakefileGener
}
monitor.setTaskName(taskName);
+ createToolchainCMakeFile(workingDir);
+
// Create the Makefiles by executing cmake
ExecuteConfigureJob job =
new ExecuteConfigureJob(
@@ -171,4 +173,109 @@ public class YoctoCMakeMakefileGenerator implements
IManagedBuilderMakefileGener
YoctoCMakeMessages.getString(YoctoCMakeMakefileGenerator.error.makeFileGenerationFailed)),
null); //$NON-NLS-1$
}
}
+
+ private String createCMakeSetStatement(String variable, String value,
String cacheOption) {
+ String setStatement = set(; //$NON-NLS-1$
+ setStatement += variable + + value; //$NON-NLS-1$
+ if(cacheOption != null !cacheOption.equals()) {
//$NON-NLS-1$
+ setStatement += + cacheOption; //$NON-NLS-1$
+ }
+ setStatement += )\n; //$NON-NLS-1$
+ return setStatement;
+ }
+
+ // Considered poky's cmake.bbclass for this method
+ private void createToolchainCMakeFile(IPath workingDir) {
+ String toolchainCMakeFileContentAsString = # CMake system name
must be something like \Linux\.\n + //$NON-NLS-1$
+ # This is important for cross-compiling.\n;
//$NON-NLS-1$
+
+ String targetArchValue = YoctoSDKUtils.getEnvValue(project,
TARGET_ARCH); //$NON-NLS-1$
+ toolchainCMakeFileContentAsString +=
createCMakeSetStatement(CMAKE_SYSTEM_PROCESSOR, targetArchValue, null);
//$NON-NLS-1$
+
+ String oeCMakeCCompilerValue =
YoctoSDKUtils.getEnvValue(project, OECMAKE_C_COMPILER); //$NON-NLS-1$
+ toolchainCMakeFileContentAsString +=
createCMakeSetStatement(CMAKE_C_COMPILER, oeCMakeCCompilerValue, null);
//$NON-NLS-1$
+
+ String oeCMakeCXXCompilerValue =
YoctoSDKUtils.getEnvValue(project, OECMAKE_CXX_COMPILER); //$NON-NLS-1$
+ toolchainCMakeFileContentAsString +=
createCMakeSetStatement(CMAKE_CXX_COMPILER, oeCMakeCXXCompilerValue, null);
//$NON-NLS-1$
+
+ String oeCMakeCFlagsValue = YoctoSDKUtils.getEnvValue(project,
OECMAKE_C_FLAGS); //$NON-NLS-1$
+ toolchainCMakeFileContentAsString +=
createCMakeSetStatement(CMAKE_C_FLAGS, //$NON-NLS-1$
+ \ + oeCMakeCFlagsValue + \, CACHE STRING
\CFLAGS\); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
+
+ String oeCMakeCXXFlagsValue =
YoctoSDKUtils.getEnvValue(project, OECMAKE_CXX_FLAGS); //$NON-NLS-1$
+ toolchainCMakeFileContentAsString +=
createCMakeSetStatement(CMAKE_CXX_FLAGS, //$NON-NLS-1$
+ \ + oeCMakeCXXFlagsValue + \, CACHE
STRING \CXXFLAGS\); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
+
+ String oeCMakeCFlagsReleaseValue =
YoctoSDKUtils.getEnvValue(project, OECMAKE_C_FLAGS_RELEASE); //$NON-NLS-1$
+ toolchainCMakeFileContentAsString +=
createCMakeSetStatement(CMAKE_C_FLAGS_RELEASE, //$NON-NLS-1$
+ \ + oeCMakeCFlagsReleaseValue + \, CACHE
STRING \CFLAGS for release\); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
+
+ String oeCMakeCXXFlagsReleaseValue =
YoctoSDKUtils.getEnvValue(project, OECMAKE_CXX_FLAGS_RELEASE); //$NON-NLS-1$
+ toolchainCMakeFileContentAsString +=
createCMakeSetStatement(CMAKE_CXX_FLAGS_RELEASE, //$NON-NLS-1$
+ \ + oeCMakeCXXFlagsReleaseValue + \,
CACHE STRING \CXXFLAGS for release\); //$NON-NLS-1$ //$NON-NLS-2$
//$NON-NLS-3$
+
+ String oeCMakeCLinkFlagsValue =
YoctoSDKUtils.getEnvValue(project, OECMAKE_C_LINK_FLAGS); //$NON-NLS-1$
+ toolchainCMakeFileContentAsString +=
createCMakeSetStatement(CMAKE_C_LINK_FLAGS, //$NON-NLS-1$
+ \ + oeCMakeCLinkFlagsValue + \, CACHE
STRING \LDFLAGS\); //$NON-NLS-1$
[yocto] [PATCH 08/13] plugins/cmake: Defined the building toolchain
From: Atanas Gegov atanas.ge...@bmw-carit.de The CMake build toolchain uses the previously defined builder and the cmake configure tool. The rest of the tools are the standard gnu compiler/ linker for C and C++. --- .../OSGI-INF/l10n/bundle.properties|3 ++ plugins/org.yocto.cmake.managedbuilder/plugin.xml | 45 2 files changed, 48 insertions(+) diff --git a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties index c66fcb9..e5db35f 100644 --- a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties +++ b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties @@ -18,6 +18,9 @@ extension.name=Yocto CMake Managed Builder # Builder builder.name=Yocto CMake Environment Builder +# Toolchain +toolchain=Yocto CMake Build (Toolchain) + # CMake configure cmakeconfigure.name=CMake configure cmakeconfigure.options=CMake Options diff --git a/plugins/org.yocto.cmake.managedbuilder/plugin.xml b/plugins/org.yocto.cmake.managedbuilder/plugin.xml index e8faadd..df1963b 100644 --- a/plugins/org.yocto.cmake.managedbuilder/plugin.xml +++ b/plugins/org.yocto.cmake.managedbuilder/plugin.xml @@ -111,5 +111,50 @@ valueType=string /option /tool +toolChain +id=org.yocto.cmake.managedbuilder.toolchain.gnu.exe +name=%toolchain +supportsManagedBuild=true +targetPlatform +id=org.yocto.cmake.managedbuilder.target.gnu.exe +isAbstract=false +superClass=cdt.managedbuild.target.gnu.platform.base +/targetPlatform +builder +id=org.yocto.cmake.managedbuilder.builder.gnu.exe +isAbstract=false +isVariableCaseSensitive=false +superClass=org.yocto.cmake.managedbuilder.builder +/builder +tool +id=org.yocto.cmake.managedbuilder.cmakeconfigure.gnu.exe +isAbstract=false +superClass=org.yocto.cmake.managedbuilder.cmakeconfigure +/tool +tool +id=org.yocto.cmake.managedbuilder.compiler.gnu.exe +isAbstract=false +natureFilter=ccnature +superClass=cdt.managedbuild.tool.gnu.cpp.compiler +/tool +tool +id=org.yocto.cmake.managedbuilder.linker.gnu.exe +isAbstract=false +natureFilter=ccnature +superClass=cdt.managedbuild.tool.gnu.cpp.linker +/tool +tool +id=org.yocto.cmake.managedbuilder.compiler.gnu.c.exe +isAbstract=false +natureFilter=cnature +superClass=cdt.managedbuild.tool.gnu.c.compiler +/tool +tool +id=org.yocto.cmake.managedbuilder.linker.gnu.c.exe +isAbstract=false +natureFilter=cnature +superClass=cdt.managedbuild.tool.gnu.c.linker +/tool +/toolChain /extension /plugin -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 09/13] plugins/cmake: Added a new category for CMake projects
From: Atanas Gegov atanas.ge...@bmw-carit.de Yocto CMake template projects should use this category. It appears in the new project wizard additionally to the existing category Yocto Project ADT CMake Project. --- .../OSGI-INF/l10n/bundle.properties|3 +++ plugins/org.yocto.cmake.managedbuilder/plugin.xml |8 2 files changed, 11 insertions(+) diff --git a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties index e5db35f..d5d6dfe 100644 --- a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties +++ b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties @@ -12,6 +12,9 @@ Bundle-Vendor = yoctoproject.org Bundle-Name = Yocto CMake Plugin +# Artefact type +yocto.cmake.artefactType=Yocto Project ADT CMake Project + # Extension name extension.name=Yocto CMake Managed Builder diff --git a/plugins/org.yocto.cmake.managedbuilder/plugin.xml b/plugins/org.yocto.cmake.managedbuilder/plugin.xml index df1963b..af26e18 100644 --- a/plugins/org.yocto.cmake.managedbuilder/plugin.xml +++ b/plugins/org.yocto.cmake.managedbuilder/plugin.xml @@ -2,6 +2,14 @@ ?eclipse version=3.4? plugin extension +point=org.eclipse.cdt.managedbuilder.core.buildProperties +propertyValue +id=org.yocto.sdk.ide.buildArtefact.cmake.exe +name=%yocto.cmake.artefactType +property=org.eclipse.cdt.build.core.buildArtefactType +/propertyValue +/extension +extension id=org.yocto.cmake.managedbuilder name=%extension.name point=org.eclipse.cdt.managedbuilder.core.buildDefinitions -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 10/13] plugins/cmake: Connect toolchain and new project category
From: Atanas Gegov atanas.ge...@bmw-carit.de
Defined a projectType that uses the new project
category. It takes the CMake toolchain to build
the project in a debug configuration. It is
possible to add further configurations (e.g.
Release with other option settings for the
configure tool).
---
.../OSGI-INF/l10n/bundle.properties|4 +
plugins/org.yocto.cmake.managedbuilder/plugin.xml | 98
2 files changed, 102 insertions(+)
diff --git
a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
index d5d6dfe..b2c067f 100644
--- a/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
+++ b/plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties
@@ -24,6 +24,10 @@ builder.name=Yocto CMake Environment Builder
# Toolchain
toolchain=Yocto CMake Build (Toolchain)
+# Configuration names
+config.debug.name=Debug
+config.debug.description=Builds a version of the project which is ready for
debugging
+
# CMake configure
cmakeconfigure.name=CMake configure
cmakeconfigure.options=CMake Options
diff --git a/plugins/org.yocto.cmake.managedbuilder/plugin.xml
b/plugins/org.yocto.cmake.managedbuilder/plugin.xml
index af26e18..8718ae6 100644
--- a/plugins/org.yocto.cmake.managedbuilder/plugin.xml
+++ b/plugins/org.yocto.cmake.managedbuilder/plugin.xml
@@ -164,5 +164,103 @@
superClass=cdt.managedbuild.tool.gnu.c.linker
/tool
/toolChain
+projectType
+buildArtefactType=org.yocto.sdk.ide.buildArtefact.cmake.exe
+id=org.yocto.sdk.ide.projectTypeCMake
+isAbstract=false
+isTest=false
+configuration
+
buildArtefactType=org.eclipse.cdt.build.core.buildArtefactType.exe
+
buildProperties=org.eclipse.cdt.build.core.buildType=org.eclipse.cdt.build.core.buildType.debug
+cleanCommand=rm -rf
+description=%config.debug.description
+id=org.yocto.cmake.managedbuilder.configuration.gnu.exe.debug
+name=%config.debug.name
+parent=cdt.managedbuild.config.gnu.base
+toolChain
+id=org.yocto.cmake.managedbuilder.toolchain.gnu.exe.debug
+
superClass=org.yocto.cmake.managedbuilder.toolchain.gnu.exe
+supportsManagedBuild=true
+targetPlatform
+
id=org.yocto.cmake.managedbuilder.target.gnu.exe.debug
+isAbstract=false
+
superClass=org.yocto.cmake.managedbuilder.target.gnu.exe
+/targetPlatform
+builder
+cleanBuildTarget=clean
+
id=org.yocto.cmake.managedbuilder.builder.gnu.exe.debug
+isVariableCaseSensitive=false
+
superClass=org.yocto.cmake.managedbuilder.builder.gnu.exe
+/builder
+tool
+commandLinePattern=${COMMAND} ${FLAGS}
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.gnu.exe.debug
+isAbstract=false
+
superClass=org.yocto.cmake.managedbuilder.cmakeconfigure.gnu.exe
+option
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.sourcepath.gnu.exe.debug
+isAbstract=false
+
superClass=org.yocto.cmake.managedbuilder.cmakeconfigure.options.sourcepath
+/option
+option
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.toolchaincmakefilepath.gnu.exe.debug
+isAbstract=false
+
superClass=org.yocto.cmake.managedbuilder.cmakeconfigure.options.toolchaincmakefilepath
+/option
+option
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.debugsymbols.gnu.exe.debug
+isAbstract=false
+
superClass=org.yocto.cmake.managedbuilder.cmakeconfigure.options.debugsymbols
+/option
+option
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.verbosemakefile.gnu.exe.debug
+isAbstract=false
+
superClass=org.yocto.cmake.managedbuilder.cmakeconfigure.options.verbosemakefile
+/option
+option
+defaultValue=FALSE
+
id=org.yocto.cmake.managedbuilder.cmakeconfigure.options.enabledevwarn.gnu.exe.debug
+isAbstract=false
+
[yocto] [PATCH 11/13] plugins/cmake: Added CMake template projects
From: Atanas Gegov atanas.ge...@bmw-carit.de
Added a C and C++ HelloWorld template projects for
CMake. The both have the new CMake project type
and are therefore built with the CMake toolchain.
---
.../build.properties |1 +
plugins/org.yocto.cmake.managedbuilder/plugin.xml | 17 ++
.../HelloWorldCCMakeProject/src/CMakeLists.txt | 34 +++
.../HelloWorldCCMakeProject/src/main.c | 21 +++
.../HelloWorldCCMakeProject/template.properties| 31 ++
.../HelloWorldCCMakeProject/template.xml | 61
.../HelloWorldCPPCMakeProject/src/CMakeLists.txt | 34 +++
.../HelloWorldCPPCMakeProject/src/main.cpp | 21 +++
.../HelloWorldCPPCMakeProject/template.properties | 31 ++
.../HelloWorldCPPCMakeProject/template.xml | 61
10 files changed, 312 insertions(+)
create mode 100644
plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/CMakeLists.txt
create mode 100644
plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/main.c
create mode 100644
plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/template.properties
create mode 100644
plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/template.xml
create mode 100644
plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCPPCMakeProject/src/CMakeLists.txt
create mode 100644
plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCPPCMakeProject/src/main.cpp
create mode 100644
plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCPPCMakeProject/template.properties
create mode 100644
plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCPPCMakeProject/template.xml
diff --git a/plugins/org.yocto.cmake.managedbuilder/build.properties
b/plugins/org.yocto.cmake.managedbuilder/build.properties
index 3e5f9ad..3945652 100644
--- a/plugins/org.yocto.cmake.managedbuilder/build.properties
+++ b/plugins/org.yocto.cmake.managedbuilder/build.properties
@@ -3,4 +3,5 @@ output.. = bin/
bin.includes = META-INF/,\
.,\
plugin.xml,\
+ templates/,\
OSGI-INF/
diff --git a/plugins/org.yocto.cmake.managedbuilder/plugin.xml
b/plugins/org.yocto.cmake.managedbuilder/plugin.xml
index 8718ae6..7aa6671 100644
--- a/plugins/org.yocto.cmake.managedbuilder/plugin.xml
+++ b/plugins/org.yocto.cmake.managedbuilder/plugin.xml
@@ -263,4 +263,21 @@
/configuration
/projectType
/extension
+extension
+point=org.eclipse.cdt.core.templates
+template
+filterPattern=.*gcc
+
id=org.yocto.cmake.managedbuilder.template.helloWorldCCMakeProject
+isCategory=false
+
location=templates/projecttemplates/HelloWorldCCMakeProject/template.xml
+projectType=org.yocto.sdk.ide.buildArtefact.cmake.exe
+/template
+template
+filterPattern=.*g\+\+
+
id=org.yocto.cmake.managedbuilder.template.helloWorldCPPCMakeProject
+isCategory=false
+
location=templates/projecttemplates/HelloWorldCPPCMakeProject/template.xml
+projectType=org.yocto.sdk.ide.buildArtefact.cmake.exe
+/template
+/extension
/plugin
diff --git
a/plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/CMakeLists.txt
b/plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/CMakeLists.txt
new file mode 100644
index 000..e6482a7
--- /dev/null
+++
b/plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/CMakeLists.txt
@@ -0,0 +1,34 @@
+cmake_minimum_required (VERSION 2.8.1)
+
+ Project settings
+PROJECT($(projectName))
+SET(LICENSE TBD)
+
+ Build and include settings
+include_directories(
+ inc
+)
+
+link_directories(
+ ${LINK_DIRECTORIES}
+)
+
+
+file(GLOB SOURCES
+ src/*.c
+)
+
+add_executable(
+ $(projectName)
+
+ ${SOURCES}
+)
+
+TARGET_LINK_LIBRARIES(
+ $(projectName)
+)
+
+ Install targets
+INSTALL(TARGETS $(projectName)
+ RUNTIME DESTINATION usr/bin
+)
diff --git
a/plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/main.c
b/plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/main.c
new file mode 100644
index 000..78b4e23
--- /dev/null
+++
b/plugins/org.yocto.cmake.managedbuilder/templates/projecttemplates/HelloWorldCCMakeProject/src/main.c
@@ -0,0 +1,21 @@
+/** @mainpage $(projectName) - $(vendor)
+ *
+ * @author $(author) $(email)
+ * @version $(projectVersion)
+**/
+
+
[yocto] [PATCH 12/13] plugins/sdk.ide: Adapted RemoteDebugLauncher for CMake projects
From: Atanas Gegov atanas.ge...@bmw-carit.de
The Yocto CMake projects are built for more
clarity in a Debug folder and not in the source
tree. The binary is therefore not inside the src
folder but in the Debug folder.
---
.../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
index 669157b..287de15 100644
--- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java
@@ -303,10 +303,15 @@ public class YoctoSDKUtils {
//TWEAK avoid loading default values in
org.eclipse.cdt.launch.remote.tabs.RemoteCDebuggerTab
w_copy.setAttribute(org.eclipse.cdt.launch.remote.RemoteCDSFDebuggerTab.DEFAULTS_SET,true);
w_copy.setAttribute(ICDTLaunchConfigurationConstants.ATTR_PROJECT_NAME,
projectName);
-
if(!project.hasNature(YoctoSDKEmptyProjectNature.YoctoSDK_EMPTY_NATURE_ID))
- {
- String project_src = src/+projectName;
-
w_copy.setAttribute(ICDTLaunchConfigurationConstants.ATTR_PROGRAM_NAME,
project_src);
+ if
(!project.hasNature(YoctoSDKEmptyProjectNature.YoctoSDK_EMPTY_NATURE_ID)) {
+ String pathToCompiledBinary = ;
+ if
(project.hasNature(YoctoSDKCMakeProjectNature.YoctoSDK_CMAKE_NATURE_ID)) {
+ pathToCompiledBinary = Debug/;
+ } else {
+ pathToCompiledBinary = src/;
+ }
+ pathToCompiledBinary += projectName;
+
w_copy.setAttribute(ICDTLaunchConfigurationConstants.ATTR_PROGRAM_NAME,
pathToCompiledBinary);
}
w_copy.doSave();
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 13/13] features/sdk: Added CMake plugin to sdk feature
From: Atanas Gegov atanas.ge...@bmw-carit.de Made the CMake extension plugin a part of the Yocto sdk feature. --- features/org.yocto.sdk/feature.xml |6 ++ 1 file changed, 6 insertions(+) diff --git a/features/org.yocto.sdk/feature.xml b/features/org.yocto.sdk/feature.xml index cca6534..03eac73 100644 --- a/features/org.yocto.sdk/feature.xml +++ b/features/org.yocto.sdk/feature.xml @@ -93,4 +93,10 @@ version=0.0.0 unpack=false/ + plugin + id=org.yocto.cmake.managedbuilder + download-size=0 + install-size=0 + version=0.0.0 + unpack=false/ /feature -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu: vnc server running on ::1:5900
On Wednesday 22 May 2013 18:19:40 Burton, Ross wrote: On 22 May 2013 18:12, varun bhatnagar varun292...@gmail.com wrote: Thanks Burton, Ross Will try this at my workplace. And is this a bug? No. Make it require SDL and people object, make it always build without SDL and people object. So the dependency is floating. More precisely, this allows people to build qemu-native both on headless servers and on desktops that do have a display without any need to configure anything. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with Python in pre-built SDK
On 16 May 2013 22:53, Ben Warren ben.war...@spidercloud.com wrote: I'm having other Yocto problems using the stock Ubuntu x86_64 toolchain, so decided to install one using the instructions in section 2.1.2 (Using a Cross-Toolchain Tarball) of the Yocto Project Application Developer's Guide. What are these other problems? Ubuntu should work fine as a host. ImportError: No module named fcntl So it looks like the Python included with the SDK is crippled or mis-configured: Yeah, the Python we build is split up massively, so clearly the SDK is missing the packages that are needed to run bitbake. But as I said, using our SDK to build is over-complicating things as Ubuntu should work fine. What problems were you seeing? Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] eo_filter_out not working
Hi Johan,
On Thursday 23 May 2013 08:59:03 Johan Thelin wrote:
I'm trying to build the packagegroup-core-p1 from the meta-ivi layer,
but I would like to remove the RRECOMMENDS as I don't want X11. To do
this, I've added a packagegroup-core-p1.bbappend to my own layer. In
this file I've tried the following options:
Attempt #1
RRECOMMENDS_packagegroup-core-p1 :=
${@oe_filter_out('packagegroup-xserver-ivi',
'${RRECOMMENDS_packagegroup-core-p1}', d)}
ERROR: ExpansionError during parsing
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-ivi/recipes-yocto-ivi/p
ackagegroups/packagegroup-core-p1.bb: Failure expanding variable
RRECOMMENDS_packagegroup-core-p1[:=],
expression was ${@oe_filter_out('packagegroup-xserver-ivi',
'${RRECOMMENDS_packagegroup-core-p1}', d)} which triggered exception
SyntaxError: EOL while scanning string literal
(RRECOMMENDS_packagegroup-core-p1[:=], line 1)
I read this as RECOMMENDS_packagegroup-core-p1 is not yet set, so the
oe_filter_out part fails.
Attempt #2
RRECOMMENDS_packagegroup-core-p1 := foo
WARNING: Variable key RRECOMMENDS_${PN} (packagegroup-xserver-ivi
) replaces original key RRECOMMENDS_packagegroup-core-p1 (foo).
This sort of explains why attempt #1 fails, as it seems that the bb is
evaluated after the bbappend.
It's not specifically about the order of evaluation between the bb and the
bbappend, what this is saying is assignment statements where the variable name
on the LHS contains references to other variables will be evaluated after
assignment statements that don't.
Unfortunately I think this means this kind of expression can't work, because
at the time of the immediate evaluation, RDEPENDS_packagegroup-core-p1 (which
is what RDEPENDS_${PN} is later expanded to) isn't available. I tried to get
the value specifically of RDEPENDS_${PN} in an anonymous python function but
that doesn't seem to work either.
I think for this case you're probably better off just setting the value as
desired rather than trying to mangle the original value. When this kind of
situation arises it usually indicates the recipe being appended needs to be
changed to be more flexible instead of trying to work around its inflexibility
in the bbappend.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] eo_filter_out not working
Hi Paul,
On 23 May 2013 13:04, Paul Eggleton paul.eggle...@linux.intel.com wrote:
Hi Johan,
On Thursday 23 May 2013 08:59:03 Johan Thelin wrote:
I'm trying to build the packagegroup-core-p1 from the meta-ivi layer,
but I would like to remove the RRECOMMENDS as I don't want X11. To do
this, I've added a packagegroup-core-p1.bbappend to my own layer. In
this file I've tried the following options:
Attempt #1
RRECOMMENDS_packagegroup-core-p1 :=
${@oe_filter_out('packagegroup-xserver-ivi',
'${RRECOMMENDS_packagegroup-core-p1}', d)}
ERROR: ExpansionError during parsing
/home/e8johan/work/yocto/pelagicore-bsp/sources/meta-ivi/recipes-yocto-ivi/p
ackagegroups/packagegroup-core-p1.bb: Failure expanding variable
RRECOMMENDS_packagegroup-core-p1[:=],
expression was ${@oe_filter_out('packagegroup-xserver-ivi',
'${RRECOMMENDS_packagegroup-core-p1}', d)} which triggered exception
SyntaxError: EOL while scanning string literal
(RRECOMMENDS_packagegroup-core-p1[:=], line 1)
I read this as RECOMMENDS_packagegroup-core-p1 is not yet set, so the
oe_filter_out part fails.
Attempt #2
RRECOMMENDS_packagegroup-core-p1 := foo
WARNING: Variable key RRECOMMENDS_${PN} (packagegroup-xserver-ivi
) replaces original key RRECOMMENDS_packagegroup-core-p1 (foo).
This sort of explains why attempt #1 fails, as it seems that the bb is
evaluated after the bbappend.
It's not specifically about the order of evaluation between the bb and the
bbappend, what this is saying is assignment statements where the variable name
on the LHS contains references to other variables will be evaluated after
assignment statements that don't.
Unfortunately I think this means this kind of expression can't work, because
at the time of the immediate evaluation, RDEPENDS_packagegroup-core-p1 (which
is what RDEPENDS_${PN} is later expanded to) isn't available. I tried to get
the value specifically of RDEPENDS_${PN} in an anonymous python function but
that doesn't seem to work either.
I was actually able to make it work (thanks to a friendly colleague)
with an anonymous python function:
python () {
rrec = bb.data.getVar('RRECOMMENDS_packagegroup-core-p1', d, 1)
if rrec:
rrec = rrec.replace(packagegroup-xserver-ivi, )
bb.data.setVar('RRECOMMENDS_packagegroup-core-p1', rrec, d)
}
I don't know why the original oe_filter_out didn't work, but this does
the trick for me, so I'm good.
Cheers,
Johan
I think for this case you're probably better off just setting the value as
desired rather than trying to mangle the original value. When this kind of
situation arises it usually indicates the recipe being appended needs to be
changed to be more flexible instead of trying to work around its inflexibility
in the bbappend.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] .rpm packaging weirdness of dynamic libraries
Hello. On the rootfs all of user added packages with dynamic libraries (/usr/lib) are missing the .so file soft link? If I check in the source folder in .libs created by libtool they are all there and links correctly. Eg. for the linx package: [git/lib/.libs]: ls -l liblinx* -rw-r--r-- 1 xxx rnd 46558 May 22 17:51 liblinx.a lrwxrwxrwx 1 xxx rnd13 May 22 17:51 liblinx.la - ../liblinx.la -rw-r--r-- 1 xxx rnd 911 May 22 17:51 liblinx.lai lrwxrwxrwx 1 xxx rnd16 May 22 17:51 liblinx.so - liblinx.so.0.0.0 lrwxrwxrwx 1 xxx rnd16 May 22 17:51 liblinx.so.0 - liblinx.so.0.0.0 -rwxr-xr-x 1 xxx rnd 43883 May 22 17:51 liblinx.so.0.0.0 Also in the package folder everything looks ok [linx/1.0-r0/package]: ls -l usr/lib/liblinx* -rw-r--r-- 2 xxx rnd 46558 May 22 17:51 usr/lib/liblinx.a -rwxr-xr-x 2 xxx rnd 911 May 22 17:51 usr/lib/liblinx.la lrwxrwxrwx 1 xxx rnd16 May 22 17:51 usr/lib/liblinx.so - liblinx.so.0.0.0 lrwxrwxrwx 1 xxx rnd16 May 22 17:51 usr/lib/liblinx.so.0 - liblinx.so.0.0.0 -rwxr-xr-x 2 xxx rnd 10356 May 22 17:52 usr/lib/liblinx.so.0.0.0 But in the rpm, the libs are packaged incorrectly (or at least not as expected) [1.0-r0/deploy-rpms/cortexa9_vfp]: rpm -q -filesbypkg -p linx-1.0-r0.cortexa9_vfp.rpm warning: linx-1.0-r0.cortexa9_vfp.rpm: Header V4 DSA signature: NOKEY, key ID e747fcfb linx /etc linx /etc/linxdisc.conf linx /usr linx /usr/bin linx /usr/bin/linx_basic_client linx /usr/bin/linx_basic_server linx /usr/bin/linx_bmark linx /usr/bin/linxcfg linx /usr/bin/linxdisc linx /usr/bin/linxgwcmd linx /usr/bin/linxgws linx /usr/bin/linxstat linx /usr/bin/mkcmclcon linx /usr/bin/mkethcon linx /usr/bin/mkhdlccon linx /usr/bin/mklink linx /usr/bin/mkriocon linx /usr/bin/mkshmcon linx /usr/bin/mksriocon linx /usr/bin/mktcpcon linx /usr/bin/rmcmclcon linx /usr/bin/rmethcon linx /usr/bin/rmhdlccon linx /usr/bin/rmlink linx /usr/bin/rmriocon linx /usr/bin/rmshmcon linx /usr/bin/rmsriocon linx /usr/bin/rmtcpcon linx /usr/bin/uselgws linx /usr/lib linx /usr/lib/libcfg.so.0 linx /usr/lib/libcfg.so.0.0.0 linx /usr/lib/libgw.so.0 linx /usr/lib/libgw.so.0.0.0 linx /usr/lib/liblinx.so.0 linx /usr/lib/liblinx.so.0.0.0 linx /usr/lib/libusel_linx.so.0 linx /usr/lib/libusel_linx.so.0.0.0 As can be seen in the end, there are no .so files :(, only .so.0 pointing to the exact version of the library. Has this been observed before? Have we made something wrong in our .bb file that results in this abnormality? From what I know (and also from what some of our system software require) there should always be a plain .so file for dynamic library version(s) to work as expected. I am currently on poky/master, but this has been confirmed also on official danny releases. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On 23 May 2013 15:50, Hans Beckérus hans.becke...@gmail.com wrote: But in the rpm, the libs are packaged incorrectly (or at least not as expected) There (should) also be a linx-dev package, that contains the .so symlinks. .so symlink files are only needed at compilation time for properly versioned libraries. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [eclipse-poky][branch:windows-build][PATCH 2/4] Fix recipe parsing when using Remote host
- when running a remote command on a remote target, the
TerminalServiceHostShell implementation is used for the HostShell(instead of
the LocalHostShell)
- in this case, the shell does not have two readers (input, error), and
instead it only offers one reader for both of the streams
- in the current implementation, the error stream is parsed first
because it makes more sense to check for errors before trying to parse the
output of the command
- in the remote case, since all output(error and output) will
be sent to the same reader, the needed output of the command will be parsed as
error and the output will be empty
- in order to fix this, we should look at the error lines
resulted after running a remote command if we are using a remote target
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF |1 +
.../yocto/bc/remote/utils/ProcessStreamBuffer.java | 13 ++---
.../org/yocto/bc/remote/utils/RemoteHelper.java|7 ++-
.../org/yocto/bc/remote/utils/RemoteMachine.java |6 --
.../org/yocto/bc/remote/utils/YoctoCommand.java|2 +-
5 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
b/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
index 4e57f33..68fc49e 100644
--- a/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
@@ -30,6 +30,7 @@ Import-Package: org.eclipse.cdt.managedbuilder.core,
org.eclipse.rse.core.model,
org.eclipse.rse.core.subsystems,
org.eclipse.rse.internal.services.local.shells,
+ org.eclipse.rse.internal.services.shells,
org.eclipse.rse.services,
org.eclipse.rse.services.clientserver.messages,
org.eclipse.rse.services.files,
diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ProcessStreamBuffer.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ProcessStreamBuffer.java
index e0d502c..73d0805 100644
---
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ProcessStreamBuffer.java
+++
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ProcessStreamBuffer.java
@@ -8,8 +8,10 @@ public class ProcessStreamBuffer {
private static final String WHITESPACES = \\s+;
ListString errorLines;
ListString outputLines;
+ boolean isTerminal;
- ProcessStreamBuffer(){
+ ProcessStreamBuffer(boolean isTerminal){
+ this.isTerminal = isTerminal;
errorLines = new ArrayListString();
outputLines = new ArrayListString();
}
@@ -56,8 +58,13 @@ public class ProcessStreamBuffer {
}
public String getOutputLineContaining(String arg, String pattern) {
- for (int i = outputLines.size() - 1; i = 0; i--){
- String line = outputLines.get(i);
+ ListString lines = null;
+ if (isTerminal)
+ lines = errorLines;
+ else
+ lines = outputLines;
+ for (int i = lines.size() - 1; i = 0; i--){
+ String line = lines.get(i);
if (line.contains(arg)) {
String[] tokens = line.split(\\s+);
if (Pattern.matches(pattern, tokens[0])) {
diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
index 87c8637..5b82e13 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
@@ -36,6 +36,7 @@ import org.eclipse.rse.core.model.IHost;
import org.eclipse.rse.core.model.ISystemRegistry;
import org.eclipse.rse.core.subsystems.ISubSystem;
import org.eclipse.rse.internal.services.local.shells.LocalHostShell;
+import org.eclipse.rse.internal.services.shells.TerminalServiceHostShell;
import org.eclipse.rse.services.IService;
import org.eclipse.rse.services.clientserver.messages.SystemMessageException;
import org.eclipse.rse.services.files.IFileService;
@@ -76,10 +77,6 @@ public class RemoteHelper {
return getRemoteMachine(connection).getCmdHandler();
}
- public static ProcessStreamBuffer getProcessBuffer(IHost connection) {
- return getRemoteMachine(connection).getProcessBuffer();
- }
-
public static IHostShell getHostShell(IHost connection) {
return getRemoteMachine(connection).getHostShell();
}
@@ -93,7 +90,7 @@ public class RemoteHelper {
lock = ((LocalHostShell)hostShell).getLock();
lock.lock();
}
- ProcessStreamBuffer processBuffer = new ProcessStreamBuffer();
+ ProcessStreamBuffer processBuffer = new
[yocto] [eclipse-poky][branch:windows-build][PATCH 3/4] Refactor processing of commands output
- refactored the processing of commands output in order to offer a more
extensible and abstract output processor that can be easily customized as
needed for different purposes
- the newly introduced OutputProcessor will offer:
- a method for processing the buffer it receives(either error
or output)
- abstract methods for processing an output or error lines
- abstract methods for deciding when an line(output or error)
has ended by searching for a specific character
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../bc/remote/utils/CommandOutputProcessor.java| 33 +++
.../org/yocto/bc/remote/utils/CommandRunnable.java |7 +-
.../org/yocto/bc/remote/utils/OutputProcessor.java | 102
.../org/yocto/bc/remote/utils/RemoteHelper.java| 77 +--
.../org/yocto/bc/remote/utils/RemoteMachine.java |7 +-
.../bc/remote/utils/YoctoRunnableWithProgress.java |2 +-
6 files changed, 140 insertions(+), 88 deletions(-)
create mode 100644
plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/CommandOutputProcessor.java
create mode 100644
plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/OutputProcessor.java
diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/CommandOutputProcessor.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/CommandOutputProcessor.java
new file mode 100644
index 000..4da33a4
--- /dev/null
+++
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/CommandOutputProcessor.java
@@ -0,0 +1,33 @@
+package org.yocto.bc.remote.utils;
+
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.rse.services.shells.IHostShell;
+
+public class CommandOutputProcessor extends OutputProcessor {
+
+ public CommandOutputProcessor(IProgressMonitor monitor,
+ IHostShell hostShell, CommandResponseHandler
cmdHandler, String task) {
+ super(monitor, hostShell, cmdHandler, task);
+ }
+
+ @Override
+ protected boolean isErrChStop(char ch) {
+ return (ch == '\n');
+ }
+
+ @Override
+ protected boolean isOutChStop(char ch) {
+ return (ch == '\n');
+ }
+
+ @Override
+ protected void processOutputBufferLine(char ch, String str) {
+ processBuffer.addOutputLine(str);
+ }
+
+ @Override
+ protected void processErrorBufferLine(char ch, String str) {
+ processBuffer.addErrorLine(str);
+ }
+
+}
diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/CommandRunnable.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/CommandRunnable.java
index 7406f50..f1ab9b1 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/CommandRunnable.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/CommandRunnable.java
@@ -1,13 +1,8 @@
package org.yocto.bc.remote.utils;
-import java.io.BufferedReader;
-import java.io.InputStreamReader;
-import java.util.concurrent.locks.Lock;
-
import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.rse.core.model.IHost;
-import org.eclipse.rse.services.shells.HostShellProcessAdapter;
import org.eclipse.rse.services.shells.IHostShell;
public class CommandRunnable implements Runnable{
@@ -28,7 +23,7 @@ public class CommandRunnable implements Runnable{
public void run() {
try {
hostShell = RemoteHelper.runCommandRemote(connection,
cmd, monitor);
-
cmd.setProcessBuffer(RemoteHelper.processOutput(monitor, hostShell, cmdHandler,
new char[]{'\n'}));
+
cmd.setProcessBuffer(RemoteHelper.processOutput(monitor, hostShell,
cmdHandler));
} catch (CoreException e) {
e.printStackTrace();
} catch (Exception e) {
diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/OutputProcessor.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/OutputProcessor.java
new file mode 100644
index 000..6d109e5
--- /dev/null
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/OutputProcessor.java
@@ -0,0 +1,102 @@
+package org.yocto.bc.remote.utils;
+
+import java.io.BufferedReader;
+import java.io.IOException;
+import java.io.InputStreamReader;
+import java.util.concurrent.locks.Lock;
+
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.rse.internal.services.local.shells.LocalHostShell;
+import org.eclipse.rse.internal.services.shells.TerminalServiceHostShell;
+import org.eclipse.rse.services.shells.HostShellProcessAdapter;
+import org.eclipse.rse.services.shells.IHostShell;
+
+public abstract class OutputProcessor{
+ private static final int ERROR_BUFFER = 1;
+ private static final int OUTPUT_BUFFER = 2;
+ protected String task;
+ protected
[yocto] [eclipse-poky][branch:windows-build][PATCH 4/4] Customize Output processor for git clone command and fix message display
- in the particular case of creating a new bitbake project by cloning, the
whole process is started from the context of the project wizard which is in
charge of updating the monitor of the command
- since the transfer is redirected to the RemoteHelper, somehow along
the way the reference of the wizard monitor is lost and the messages are not
displayed correctly
- in order to fix this, the parsing is done locally inside the
appropiate context using a customization of the abstract OutputProcessor
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../bc/remote/utils/YoctoRunnableWithProgress.java | 31 +++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoRunnableWithProgress.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoRunnableWithProgress.java
index 7eb7172..4005554 100644
---
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoRunnableWithProgress.java
+++
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoRunnableWithProgress.java
@@ -80,7 +80,36 @@ public class YoctoRunnableWithProgress implements
IRunnableWithProgress {
e.printStackTrace();
}
}
+ class YoctoRunnableOutputProcessor extends OutputProcessor{
+ public YoctoRunnableOutputProcessor(IProgressMonitor monitor,
+ IHostShell hostShell, CommandResponseHandler
cmdHandler,
+ String task) {
+ super(monitor, hostShell, cmdHandler, task);
+ }
+ @Override
+ protected boolean isErrChStop(char ch) {
+ return (ch == '\n' || ch == '\r');
+ }
+
+ @Override
+ protected boolean isOutChStop(char ch) {
+ return (ch == '\n');
+ }
+
+ @Override
+ protected void processOutputBufferLine(char ch, String str) {
+ processBuffer.addOutputLine(str);
+ }
+
+ @Override
+ protected void processErrorBufferLine(char ch, String str) {
+ processBuffer.addOutputLine(str);
+ if (ch == '\r')
+ reportProgress(str);
+ }
+
+ }
class YoctoThread implements Runnable{
private IHost connection;
@@ -98,7 +127,7 @@ public class YoctoRunnableWithProgress implements
IRunnableWithProgress {
public void run() {
try {
hostShell =
RemoteHelper.runCommandRemote(this.connection, command, monitor);
-
command.setProcessBuffer(RemoteHelper.processOutput(monitor, hostShell,
cmdHandler));
+ command.setProcessBuffer(new
YoctoRunnableOutputProcessor(monitor, hostShell, cmdHandler,
taskName).processOutput());
} catch (CoreException e) {
e.printStackTrace();
} catch (Exception e) {
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu: vnc server running on ::1:5900
Hi, Followed the instructions given by you and it workedthanks a lot... But now I got one more problem..when I tried logging in I found out that my keyboard's key mapping got changed and it was not working. How can I fix this :( // Varun On Wed, May 22, 2013 at 10:49 PM, Burton, Ross ross.bur...@intel.comwrote: On 22 May 2013 18:12, varun bhatnagar varun292...@gmail.com wrote: Thanks Burton, Ross Will try this at my workplace. And is this a bug? No. Make it require SDL and people object, make it always build without SDL and people object. So the dependency is floating. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu: vnc server running on ::1:5900
On 23 May 2013 16:08, varun bhatnagar varun292...@gmail.com wrote: But now I got one more problem..when I tried logging in I found out that my keyboard's key mapping got changed and it was not working. How can I fix this :( It defaults to the US layout. To be honest I'm not sure how to change the default layout, sorry. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 4:55 PM, Burton, Ross ross.bur...@intel.com wrote: On 23 May 2013 15:50, Hans Beckérus hans.becke...@gmail.com wrote: But in the rpm, the libs are packaged incorrectly (or at least not as expected) There (should) also be a linx-dev package, that contains the .so symlinks. .so symlink files are only needed at compilation time for properly versioned libraries. Ross Well, yes and no ;) If I look in /lib there are plenty of libraries that comes with .so files so it seems they are needed in some cases, right? Also, since part of our system software is doing loading of dynamic libraries themselves using dlopen() it is *very* hard to enforce removal of .so files since that piece of software does not know what particular version of the library it should use. It should load whatever .so points to, most commonly the latest version. So, is there some way for us to make sure .so files are also part of the .rpm? we do not wish to install the -dev variant since it also pollutes the system with a lot of other not needed stuff. Since /lib is having a lot of of .so files it must be possible, or? Actually, I have never seen a system that does not include also the .so files? Not even embedded ones. They are only soft links so flash/ram/disk space is not really an issue here. Hans On Thu, May 23, 2013 at 4:55 PM, Burton, Ross ross.bur...@intel.com wrote: On 23 May 2013 15:50, Hans Beckérus hans.becke...@gmail.com wrote: But in the rpm, the libs are packaged incorrectly (or at least not as expected) There (should) also be a linx-dev package, that contains the .so symlinks. .so symlink files are only needed at compilation time for properly versioned libraries. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
Coming to think of it, since the .so requirement is only applicable to small subset of our libraries, I guess we could make an init script that creates the .so soft links according to what is currently the latest version on the system. Otherwise we would need to update the software doing dlopen() every time the library major version is stepped. Since that software is not under our complete control that could end up very difficult. Otherwise, I fully agree that the .so files should not really be needed if only ld is involved. Why can not things just be simple ;) Hans On Thu, May 23, 2013 at 5:25 PM, Hans Beckérus hans.becke...@gmail.com wrote: On Thu, May 23, 2013 at 4:55 PM, Burton, Ross ross.bur...@intel.com wrote: On 23 May 2013 15:50, Hans Beckérus hans.becke...@gmail.com wrote: But in the rpm, the libs are packaged incorrectly (or at least not as expected) There (should) also be a linx-dev package, that contains the .so symlinks. .so symlink files are only needed at compilation time for properly versioned libraries. Ross Well, yes and no ;) If I look in /lib there are plenty of libraries that comes with .so files so it seems they are needed in some cases, right? Also, since part of our system software is doing loading of dynamic libraries themselves using dlopen() it is *very* hard to enforce removal of .so files since that piece of software does not know what particular version of the library it should use. It should load whatever .so points to, most commonly the latest version. So, is there some way for us to make sure .so files are also part of the .rpm? we do not wish to install the -dev variant since it also pollutes the system with a lot of other not needed stuff. Since /lib is having a lot of of .so files it must be possible, or? Actually, I have never seen a system that does not include also the .so files? Not even embedded ones. They are only soft links so flash/ram/disk space is not really an issue here. Hans On Thu, May 23, 2013 at 4:55 PM, Burton, Ross ross.bur...@intel.com wrote: On 23 May 2013 15:50, Hans Beckérus hans.becke...@gmail.com wrote: But in the rpm, the libs are packaged incorrectly (or at least not as expected) There (should) also be a linx-dev package, that contains the .so symlinks. .so symlink files are only needed at compilation time for properly versioned libraries. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On 23 May 2013 16:25, Hans Beckérus hans.becke...@gmail.com wrote: Well, yes and no ;) If I look in /lib there are plenty of libraries that comes with .so files so it seems they are needed in some cases, right? Also, since part of our system software is doing loading of dynamic libraries themselves using dlopen() it is *very* hard to enforce removal of .so files since that piece of software does not know what particular version of the library it should use. It should load whatever .so points to, most commonly the latest version. So, is there some way for us to make sure .so files are also part of the .rpm? we do not wish to install the -dev variant since it also pollutes the system with a lot of other not needed stuff. Since /lib is having a lot of of .so files it must be possible, or? Actually, I have never seen a system that does not include also the .so files? Not even embedded ones. They are only soft links so flash/ram/disk space is not really an issue here. *Every* mainstream linux distribution will not ship .so symlinks unless you've installed the development files, or they are needed for some reason (generally, the .so won't be a symlink in that case). If a particular library is designed to be unversioned and dlopen'd using a .so filename, then change the FILES as appropriate. If your package is dlopening arbitrary versioned libraries though libfoo.so filenames then you can either do more work and find the real name, or mess around with the packaging yourself. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 5:47 PM, Burton, Ross ross.bur...@intel.com wrote: On 23 May 2013 16:25, Hans Beckérus hans.becke...@gmail.com wrote: Well, yes and no ;) If I look in /lib there are plenty of libraries that comes with .so files so it seems they are needed in some cases, right? Also, since part of our system software is doing loading of dynamic libraries themselves using dlopen() it is *very* hard to enforce removal of .so files since that piece of software does not know what particular version of the library it should use. It should load whatever .so points to, most commonly the latest version. So, is there some way for us to make sure .so files are also part of the .rpm? we do not wish to install the -dev variant since it also pollutes the system with a lot of other not needed stuff. Since /lib is having a lot of of .so files it must be possible, or? Actually, I have never seen a system that does not include also the .so files? Not even embedded ones. They are only soft links so flash/ram/disk space is not really an issue here. *Every* mainstream linux distribution will not ship .so symlinks unless you've installed the development files, or they are needed for some reason (generally, the .so won't be a symlink in that case). If a particular library is designed to be unversioned and dlopen'd using a .so filename, then change the FILES as appropriate. If your package is dlopening arbitrary versioned libraries though libfoo.so filenames then you can either do more work and find the real name, or mess around with the packaging yourself. Ross Sure. I am not questioning mainstream decision not to ship the .so symlinks. I most likely have never encountered real mainstream embedded systems before ;) Only home-brewed (we-can-do-it-ourselves) things. What I needed was some sort of pointer on how to handle the case when you do need to violate the mainstream rules :( I will play around with the FILES setting to see if it will get us were we need to be. I really do not wish to tamper with the packaging routines. It does what it does, with an obviously good reason too :P Thanks! Hans On Thu, May 23, 2013 at 5:47 PM, Burton, Ross ross.bur...@intel.com wrote: On 23 May 2013 16:25, Hans Beckérus hans.becke...@gmail.com wrote: Well, yes and no ;) If I look in /lib there are plenty of libraries that comes with .so files so it seems they are needed in some cases, right? Also, since part of our system software is doing loading of dynamic libraries themselves using dlopen() it is *very* hard to enforce removal of .so files since that piece of software does not know what particular version of the library it should use. It should load whatever .so points to, most commonly the latest version. So, is there some way for us to make sure .so files are also part of the .rpm? we do not wish to install the -dev variant since it also pollutes the system with a lot of other not needed stuff. Since /lib is having a lot of of .so files it must be possible, or? Actually, I have never seen a system that does not include also the .so files? Not even embedded ones. They are only soft links so flash/ram/disk space is not really an issue here. *Every* mainstream linux distribution will not ship .so symlinks unless you've installed the development files, or they are needed for some reason (generally, the .so won't be a symlink in that case). If a particular library is designed to be unversioned and dlopen'd using a .so filename, then change the FILES as appropriate. If your package is dlopening arbitrary versioned libraries though libfoo.so filenames then you can either do more work and find the real name, or mess around with the packaging yourself. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QA rdepends issue when building xerces-c
Dear Yocto users,
I created a recipe for xerces-c (see below), and when bitbaking, the
error ERROR: QA Issue: xerces-c rdepends on xerces-c-dev is
produced.
I added RPROVIDES_${PN} += xerces-c-dev to the recipe, incremented
the PR number, and baked again but still without success.
I also tried INSANE_SKIP_${PN} += dev-so without any luck.
Might you know how to solve this?
The recipe:
DESCRIPTION = Xerces-c is a validating xml parser written in C++
HOMEPAGE = http://xerces.apache.org/xerces-c/;
LICENSE = MIT
LIC_FILES_CHKSUM = file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57
PR = r6
SRC_URI = file://xerces-c-${PV}.tar.gz
SRC_URI[md5sum] = 6a8ec45d83c8cfb1584c5a5345cb51ae
S = ${WORKDIR}/xerces-c-${PV}
inherit autotools lib_package pkgconfig gettext
RPROVIDES_${PN} += xerces-c-dev
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus hans.becke...@gmail.com wrote:
On Thu, May 23, 2013 at 5:47 PM, Burton, Ross ross.bur...@intel.com wrote:
On 23 May 2013 16:25, Hans Beckérus hans.becke...@gmail.com wrote:
Well, yes and no ;) If I look in /lib there are plenty of libraries
that comes with .so files so it seems they are needed in some cases,
right? Also, since part of our system software is doing loading of
dynamic libraries themselves using dlopen() it is *very* hard to
enforce removal of .so files since that piece of software does not
know what particular version of the library it should use. It should
load whatever .so points to, most commonly the latest version. So, is
there some way for us to make sure .so files are also part of the
.rpm? we do not wish to install the -dev variant since it also
pollutes the system with a lot of other not needed stuff. Since /lib
is having a lot of of .so files it must be possible, or?
Actually, I have never seen a system that does not include also the
.so files? Not even embedded ones. They are only soft links so
flash/ram/disk space is not really an issue here.
*Every* mainstream linux distribution will not ship .so symlinks
unless you've installed the development files, or they are needed for
some reason (generally, the .so won't be a symlink in that case). If
a particular library is designed to be unversioned and dlopen'd using
a .so filename, then change the FILES as appropriate. If your package
is dlopening arbitrary versioned libraries though libfoo.so filenames
then you can either do more work and find the real name, or mess
around with the packaging yourself.
Ross
Sure. I am not questioning mainstream decision not to ship the .so
symlinks. I most likely have never encountered real mainstream
embedded systems before ;) Only home-brewed (we-can-do-it-ourselves)
things. What I needed was some sort of pointer on how to handle the
case when you do need to violate the mainstream rules :(
I will play around with the FILES setting to see if it will get us
were we need to be. I really do not wish to tamper with the packaging
routines. It does what it does, with an obviously good reason too :P
Thanks!
Hans
Hmm. I tried the FILES trick, but either I am doing something wrong or
FILES does not really affect whats getting into the .rpm? This is what
I tried in our recipe
FILES_${PN} += ${exec_prefix}/usr/lib/libelinx.so
FILES_${PN} += ${exec_prefix}/usr/lib/libepmq.so
But I see now that dev RPM in addition to the normal RPM is what we
need besides the .la files but I think we we can live with that ;) Is
there some simple/clever trick to have both the standard and the dev
RPM being installed on the rootfs?
Hans
On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus hans.becke...@gmail.com wrote:
On Thu, May 23, 2013 at 5:47 PM, Burton, Ross ross.bur...@intel.com wrote:
On 23 May 2013 16:25, Hans Beckérus hans.becke...@gmail.com wrote:
Well, yes and no ;) If I look in /lib there are plenty of libraries
that comes with .so files so it seems they are needed in some cases,
right? Also, since part of our system software is doing loading of
dynamic libraries themselves using dlopen() it is *very* hard to
enforce removal of .so files since that piece of software does not
know what particular version of the library it should use. It should
load whatever .so points to, most commonly the latest version. So, is
there some way for us to make sure .so files are also part of the
.rpm? we do not wish to install the -dev variant since it also
pollutes the system with a lot of other not needed stuff. Since /lib
is having a lot of of .so files it must be possible, or?
Actually, I have never seen a system that does not include also the
.so files? Not even embedded ones. They are only soft links so
flash/ram/disk space is not really an issue here.
*Every* mainstream linux distribution will not ship .so symlinks
unless you've installed the development files, or they are needed for
some reason (generally, the .so won't be a symlink in that case). If
a particular library is designed to be unversioned and dlopen'd using
a .so filename, then change the FILES as appropriate. If your package
is dlopening arbitrary versioned libraries though libfoo.so filenames
then you can either do more work and find the real name, or mess
around with the packaging yourself.
Ross
Sure. I am not questioning mainstream decision not to ship the .so
symlinks. I most likely have never encountered real mainstream
embedded systems before ;) Only home-brewed (we-can-do-it-ourselves)
things. What I needed was some sort of pointer on how to handle the
case when you do need to violate the mainstream rules :(
I will play around with the FILES setting to see if it will get us
were we need to be. I really do not wish to tamper with the packaging
routines. It does what it does, with an obviously good reason too :P
Thanks!
Hans
On
Re: [yocto] [PATCH][eclipse-poky] systemtap: add possibility for user to point to his build folder
Hi Andrian,
Sorry, I was traveling and missed this patch. And seems it's not applicable to
the latest master. Can you rebase and resend?
Thanks,
Jessica
-Original Message-
From: Adrian Dudau [mailto:adrian.du...@enea.com]
Sent: Friday, May 03, 2013 1:53 AM
To: Zhang, Jessica
Cc: yocto@yoctoproject.org
Subject: Re: [PATCH][eclipse-poky] systemtap: add possibility for user to point
to his build folder
On Mon, 2013-04-29 at 14:15 +0200, Adrian Dudau wrote:
[Yocto #4223]
Signed-off-by: Adrian Dudau adrian.du...@enea.com
---
.../src/org/yocto/sdk/remotetools/Messages.java|1 +
.../org/yocto/sdk/remotetools/ShellSession.java|6 +++--
.../sdk/remotetools/actions/SystemtapHandler.java |3 ++-
.../sdk/remotetools/actions/SystemtapModel.java|6 +++--
.../actions/SystemtapSettingDialog.java| 28
.../org/yocto/sdk/remotetools/messages.properties |1 +
6 files changed, 40 insertions(+), 5 deletions(-)
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Mess
ages.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Mess
ages.java
index 66ba62b..cbf2b05 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Mess
ages.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/
+++ Messages.java
@@ -40,6 +40,7 @@ public class Messages extends NLS {
public static String TerminalViewer_text;
//public static String Systemtap_KO_Text;
public static String Metadata_Location;
+ public static String Builddir_Location;
public static String User_ID;
public static String Remote_Host;
public static String Systemtap_Script; diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Shel
lSession.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Shel
lSession.java
index 5602798..cbc8e55 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Shel
lSession.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/
+++ ShellSession.java
@@ -66,12 +66,14 @@ public class ShellSession {
private String shellPath = null;
private final String initCmd;
private final File root;
+ private final File builddir;
private OutputStreamWriter out;
- public ShellSession(int shellType, File root, String initCmd,
OutputStream out) throws IOException {
+ public ShellSession(int shellType, File root, File builddir, String
+initCmd, OutputStream out) throws IOException {
this.root = root;
+ this.builddir = builddir;
this.initCmd = initCmd;
if (out == null) {
this.out = new OutputStreamWriter(null); @@ -95,7 +97,7
@@ public
class ShellSession {
}
if (initCmd != null) {
- execute(source + initCmd);
+ execute(source + initCmd + +
builddir.getAbsolutePath());
}
}
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/acti
ons/SystemtapHandler.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/acti
ons/SystemtapHandler.java
index 87094ee..dc11e39 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/acti
ons/SystemtapHandler.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/
+++ actions/SystemtapHandler.java
@@ -35,6 +35,7 @@ public class SystemtapHandler extends
AbstractHandler {
setting.open();
String metadata_location =
((SystemtapSettingDialog)setting).getMetadataLocation();
+ String builddir_location =
+((SystemtapSettingDialog)setting).getBuilddirLocation();
String remote_host =
((SystemtapSettingDialog)setting).getRemoteHost();
String user_id = ((SystemtapSettingDialog)setting).getUserID();
String systemtap_script =
((SystemtapSettingDialog)setting).getSystemtapScript();
@@ -42,7 +43,7 @@ public class SystemtapHandler extends
AbstractHandler {
if(setting.open() == BaseSettingDialog.OK) {
IProgressService progressService =
PlatformUI.getWorkbench().getProgressService();
- SystemtapModel op = new
SystemtapModel(metadata_location,remote_host, user_id, systemtap_script,
+ SystemtapModel op = new
SystemtapModel(metadata_location,
+builddir_location, remote_host, user_id, systemtap_script,
systemtap_args,window.getShell().getDisplay());
try {
progressService.busyCursorWhile(op);
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/acti
ons/SystemtapModel.java
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 7:16 PM, Hans Beckérus hans.becke...@gmail.com wrote:
On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus hans.becke...@gmail.com
wrote:
On Thu, May 23, 2013 at 5:47 PM, Burton, Ross ross.bur...@intel.com wrote:
On 23 May 2013 16:25, Hans Beckérus hans.becke...@gmail.com wrote:
Well, yes and no ;) If I look in /lib there are plenty of libraries
that comes with .so files so it seems they are needed in some cases,
right? Also, since part of our system software is doing loading of
dynamic libraries themselves using dlopen() it is *very* hard to
enforce removal of .so files since that piece of software does not
know what particular version of the library it should use. It should
load whatever .so points to, most commonly the latest version. So, is
there some way for us to make sure .so files are also part of the
.rpm? we do not wish to install the -dev variant since it also
pollutes the system with a lot of other not needed stuff. Since /lib
is having a lot of of .so files it must be possible, or?
Actually, I have never seen a system that does not include also the
.so files? Not even embedded ones. They are only soft links so
flash/ram/disk space is not really an issue here.
*Every* mainstream linux distribution will not ship .so symlinks
unless you've installed the development files, or they are needed for
some reason (generally, the .so won't be a symlink in that case). If
a particular library is designed to be unversioned and dlopen'd using
a .so filename, then change the FILES as appropriate. If your package
is dlopening arbitrary versioned libraries though libfoo.so filenames
then you can either do more work and find the real name, or mess
around with the packaging yourself.
Ross
Sure. I am not questioning mainstream decision not to ship the .so
symlinks. I most likely have never encountered real mainstream
embedded systems before ;) Only home-brewed (we-can-do-it-ourselves)
things. What I needed was some sort of pointer on how to handle the
case when you do need to violate the mainstream rules :(
I will play around with the FILES setting to see if it will get us
were we need to be. I really do not wish to tamper with the packaging
routines. It does what it does, with an obviously good reason too :P
Thanks!
Hans
Hmm. I tried the FILES trick, but either I am doing something wrong or
FILES does not really affect whats getting into the .rpm? This is what
I tried in our recipe
FILES_${PN} += ${exec_prefix}/usr/lib/libelinx.so
FILES_${PN} += ${exec_prefix}/usr/lib/libepmq.so
But I see now that dev RPM in addition to the normal RPM is what we
need besides the .la files but I think we we can live with that ;) Is
there some simple/clever trick to have both the standard and the dev
RPM being installed on the rootfs?
Oops! Already spotted my typo there. It should of course be
FILES_${PN} += ${exec_prefix}/lib/libelinx.so
FILES_${PN} += ${exec_prefix}/lib/libepmq.so
But unfortunately I did not make any difference to the .rpm file :(
Hans
On Thu, May 23, 2013 at 7:16 PM, Hans Beckérus hans.becke...@gmail.com wrote:
On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus hans.becke...@gmail.com
wrote:
On Thu, May 23, 2013 at 5:47 PM, Burton, Ross ross.bur...@intel.com wrote:
On 23 May 2013 16:25, Hans Beckérus hans.becke...@gmail.com wrote:
Well, yes and no ;) If I look in /lib there are plenty of libraries
that comes with .so files so it seems they are needed in some cases,
right? Also, since part of our system software is doing loading of
dynamic libraries themselves using dlopen() it is *very* hard to
enforce removal of .so files since that piece of software does not
know what particular version of the library it should use. It should
load whatever .so points to, most commonly the latest version. So, is
there some way for us to make sure .so files are also part of the
.rpm? we do not wish to install the -dev variant since it also
pollutes the system with a lot of other not needed stuff. Since /lib
is having a lot of of .so files it must be possible, or?
Actually, I have never seen a system that does not include also the
.so files? Not even embedded ones. They are only soft links so
flash/ram/disk space is not really an issue here.
*Every* mainstream linux distribution will not ship .so symlinks
unless you've installed the development files, or they are needed for
some reason (generally, the .so won't be a symlink in that case). If
a particular library is designed to be unversioned and dlopen'd using
a .so filename, then change the FILES as appropriate. If your package
is dlopening arbitrary versioned libraries though libfoo.so filenames
then you can either do more work and find the real name, or mess
around with the packaging yourself.
Ross
Sure. I am not questioning mainstream decision not to ship the .so
symlinks. I most likely have never encountered real mainstream
embedded systems before ;) Only
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On 23 May 2013 18:16, Hans Beckérus hans.becke...@gmail.com wrote:
Hmm. I tried the FILES trick, but either I am doing something wrong or
FILES does not really affect whats getting into the .rpm? This is what
I tried in our recipe
FILES_${PN} += ${exec_prefix}/usr/lib/libelinx.so
FILES_${PN} += ${exec_prefix}/usr/lib/libepmq.so
Use ${libdir} instead of exec_prefix/usr/lib, and I guess the default
FILES_${PN}-dev is taking the files first. Try setting that to .
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2 0/6] Separate org.yocto.remote.utils plugin
Merged to eclipse-poky master. Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Ioana Grigoropol Sent: Monday, May 13, 2013 2:26 AM To: yocto@yoctoproject.org Subject: [yocto] [PATCH v2 0/6] Separate org.yocto.remote.utils plugin - initial commit populate for remote utils common plugin Ioana Grigoropol (6): Initial commit for separate remote utilities plugin Move RSEHelper to a separate plugin Move RemoteShellExec to separate plugin Move ShellSession to org.yocto.remote.utils separate plugin Move CommonHelper to org.yocto.remote.utils separate plugin Move TerminalHandler to org.yocto.remote.utils plugins/org.yocto.remote.utils/.classpath |7 + plugins/org.yocto.remote.utils/.project| 28 ++ .../.settings/org.eclipse.jdt.core.prefs |7 + .../org.yocto.remote.utils/META-INF/MANIFEST.MF| 28 ++ plugins/org.yocto.remote.utils/build.properties|4 + .../org.yocto.remote.utils/resources/ust_tar.sh| 19 + .../org.yocto.remote.utils/resources/yocto_tool.sh | 125 ++ .../org.yocto.remote.utils/resources/yocto_ust.sh | 35 ++ .../src/org/yocto/remote/utils/Activator.java | 62 +++ .../src/org/yocto/remote/utils/CommonHelper.java | 46 +++ .../src/org/yocto/remote/utils/Messages.java | 35 ++ .../src/org/yocto/remote/utils/RSEHelper.java | 344 .../org/yocto/remote/utils/RemoteShellExec.java| 140 +++ .../src/org/yocto/remote/utils/ShellSession.java | 327 +++ .../org/yocto/remote/utils/TerminalHandler.java| 128 ++ .../org.yocto.sdk.remotetools/META-INF/MANIFEST.MF |3 +- .../org.yocto.sdk.remotetools/resources/ust_tar.sh | 19 - .../resources/yocto_tool.sh| 125 -- .../resources/yocto_ust.sh | 35 -- .../org/yocto/sdk/remotetools/CommonHelper.java| 44 -- .../src/org/yocto/sdk/remotetools/RSEHelper.java | 419 .../org/yocto/sdk/remotetools/ShellSession.java| 341 .../yocto/sdk/remotetools/actions/BaseModel.java |4 +- .../sdk/remotetools/actions/BaseSettingDialog.java |2 +- .../sdk/remotetools/actions/DialogHandler.java |1 + .../sdk/remotetools/actions/OprofileModel.java |2 +- .../sdk/remotetools/actions/SystemtapModel.java|2 +- .../actions/SystemtapSettingDialog.java|2 +- .../sdk/remotetools/actions/TerminalHandler.java | 128 -- .../sdk/remotetools/remote/RemoteShellExec.java| 149 --- 30 files changed, 1344 insertions(+), 1267 deletions(-) create mode 100644 plugins/org.yocto.remote.utils/.classpath create mode 100644 plugins/org.yocto.remote.utils/.project create mode 100644 plugins/org.yocto.remote.utils/.settings/org.eclipse.jdt.core.prefs create mode 100644 plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF create mode 100644 plugins/org.yocto.remote.utils/build.properties create mode 100755 plugins/org.yocto.remote.utils/resources/ust_tar.sh create mode 100755 plugins/org.yocto.remote.utils/resources/yocto_tool.sh create mode 100755 plugins/org.yocto.remote.utils/resources/yocto_ust.sh create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/Activator.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommonHelper.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/Messages.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RSEHelper.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RemoteShellExec.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/TerminalHandler.java delete mode 100755 plugins/org.yocto.sdk.remotetools/resources/ust_tar.sh delete mode 100755 plugins/org.yocto.sdk.remotetools/resources/yocto_tool.sh delete mode 100755 plugins/org.yocto.sdk.remotetools/resources/yocto_ust.sh delete mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/CommonHelper.java delete mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/RSEHelper.java delete mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/ShellSession.java delete mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/TerminalHandler.java delete mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/remote/RemoteShellExec.java -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org
Re: [yocto] [eclipse-poky][branch:windows-build][PATCH 0/4] Adapt remote bb plugin code fix remaining issues
Hi Ioana, Since we're doing the overall refactor and this part for bitbake commander need to adopt the remote.util changes that's underway, and windows-build branch shouldn't be the one that we use. Please incorporate this change to bitbake commander change to use the remote.util tool. Thanks Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Ioana Grigoropol Sent: Thursday, May 23, 2013 7:39 AM To: yocto@yoctoproject.org Subject: [yocto] [eclipse-poky][branch:windows-build][PATCH 0/4] Adapt remote bb plugin code fix remaining issues - adapted remote bitbake commander project code to use upstream changes in the LocalHostShell code - added fixes for recipe parsing - added fixes for messages displayed during git clone Ioana Grigoropol (4): Adapt usage of LocalHostShell lock and reader to upstream changes Fix recipe parsing when using Remote host Refactor processing of commands output Customize Output processor for git clone command and fix message display plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF |1 + .../bc/remote/utils/CommandOutputProcessor.java| 33 +++ .../org/yocto/bc/remote/utils/CommandRunnable.java |7 +- .../org/yocto/bc/remote/utils/OutputProcessor.java | 102 .../yocto/bc/remote/utils/ProcessStreamBuffer.java | 13 ++- .../org/yocto/bc/remote/utils/RemoteHelper.java| 65 + .../org/yocto/bc/remote/utils/RemoteMachine.java | 13 +-- .../org/yocto/bc/remote/utils/YoctoCommand.java|2 +- .../bc/remote/utils/YoctoRunnableWithProgress.java | 31 +- 9 files changed, 181 insertions(+), 86 deletions(-) create mode 100644 plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/CommandOutputProcessor.java create mode 100644 plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/OutputProcessor.java -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 8:31 PM, Burton, Ross ross.bur...@intel.com wrote:
On 23 May 2013 18:16, Hans Beckérus hans.becke...@gmail.com wrote:
Hmm. I tried the FILES trick, but either I am doing something wrong or
FILES does not really affect whats getting into the .rpm? This is what
I tried in our recipe
FILES_${PN} += ${exec_prefix}/usr/lib/libelinx.so
FILES_${PN} += ${exec_prefix}/usr/lib/libepmq.so
Use ${libdir} instead of exec_prefix/usr/lib, and I guess the default
FILES_${PN}-dev is taking the files first. Try setting that to .
Thanks. I will certainly try that.
However, I have completely changed path now ;) I think the root cause
of this entire problem is that the package is constructed wrong. Since
these .so files are modules, we need to tell libtool so it does not
create the regular versioned lib file structure. What we want is a .so
file and no links. Maybe then all of this is a no issue anymore?
elinx_drv_la_LDFLAGS = -module -avoid-version -shared
This might do the trick.
Hans
On Thu, May 23, 2013 at 8:31 PM, Burton, Ross ross.bur...@intel.com wrote:
On 23 May 2013 18:16, Hans Beckérus hans.becke...@gmail.com wrote:
Hmm. I tried the FILES trick, but either I am doing something wrong or
FILES does not really affect whats getting into the .rpm? This is what
I tried in our recipe
FILES_${PN} += ${exec_prefix}/usr/lib/libelinx.so
FILES_${PN} += ${exec_prefix}/usr/lib/libepmq.so
Use ${libdir} instead of exec_prefix/usr/lib, and I guess the default
FILES_${PN}-dev is taking the files first. Try setting that to .
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA rdepends issue when building xerces-c
On Thu, May 23, 2013 at 6:53 PM, Hartmut Behrens
hartmut.behr...@gmail.com wrote:
I also tried INSANE_SKIP_${PN} += dev-so without any luck.
Might you know how to solve this?
So including INSANE_SKIP_${PN} = dev-deps does the trick.
I tried playing around with FILES (shown below), but can't quite get
it right. The error that is issued then is ERROR: QA Issue: non
-dev/-dbg/-nativesdk package contains symlink .so ...
FILES_${PN} = ${bindir}/* ${libdir}/*
FILES_${PN}-dev = ${includedir} ${libdir}/libxerces-c.so
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Hands-on Kernel Lab dylan (1.4) update available
Hi, I'm happy to announce that the Yocto 'Hands-on Kernel Lab' has been updated for dylan (Yocto 1.4) and is available here: https://www.yoctoproject.org/sites/yoctoproject.org/files/kernel-lab-1.4.pdf The above document contains all the instructions you need to get started from scratch. Besides the updates for dylan, this version of the 'Hands-on Kernel Lab' incorporates a lot of feedback from the users of the previous version. Special thanks to Robert P. J. Day, who sent a lot of useful comments and suggestions. The topics covered are essentially the same as those in the previous version, with sections covering the use of traditional kernel recipes, custom kernel recipes, and linux-yocto recipes, along with sections discussing how to modify the kernel configuration and sources in each of those cases. It also discusses how to make use of loadable modules and how to get them into (and autoloaded into) images, how to make use of external modules, and how to enable LTSI features. Additionally, it discusses overall workflow issues including the use of local clones and bare local clones. Finally, it demonstrates how to use the yocto-bsp and yocto-kernel tools to generate board support packages and use those tools to configure and patch the kernel in the generated BSP. See below for a more complete listing of what's covered along with the lab number covering those topics. I've run through the lab twice, once on Fedora 17 and once on Ubuntu 12.04, but if you find problems, please let me know... * Creating and using a traditional kernel recipe (lab1) * Using 'bitbake -c menuconfig' to modify the kernel configuration and replace the defconfig with the new configuration (lab1) * Adding a kernel module to the kernel source and configuring it as a built-in module by adding options to the kernel defconfig (lab1) * Creating and using a linux-yocto-based kernel (lab2) * Adding a kernel module to the kernel source and configuring it as a built-in module using linux-yocto 'config fragments' (lab2) * Using the linux-yocto kernel as an LTSI kernel (configuring in an item added by the LTSI kernel which is merged into linux-yocto) (lab2) * Using an arbitrary git-based kernel via the linux-yocto-custom kernel recipe (lab3) * Adding a kernel module to the kernel source of an arbitrary git-based kernel and configuring it as a loadable module using 'config fragments' (lab3) * Actually getting the module into the image and autoloading it on boot (lab3) * Using a local clone of an arbitrary git-based kernel via the linux-yocto-custom kernel recipe to demonstrate a typical development workflow (lab4) * Modifying the locally cloned custom kernel source and verifying the changes in the new image (lab4) * Using a local clone of a linux-yocto- kernel recipe to demonstrate a typical development workflow (lab4) * Modifying the locally cloned linux-yocto kernel source and verifying the changes in the new image (lab4) * Using a 'bare' local clone of a linux-yocto- kernel recipe to demonstrate a typical development workflow (lab4) * Modifying the locally cloned 'bare' linux-yocto kernel source and verifying the changes in the new image (lab4) * Adding and using an external kernel module via a module recipe (lab4) * Using the 'Yocto BSP Tools' yocto-bsp tool generate a new Yocto BSP (lab5) * Using the 'Yocto BSP Tools' yocto-kernel tool to add kernel patches and config fragments (lab5) Thanks, Tom ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Qt5
Hi There, I am first time coming here for help on Yocto project with Qt5, I have two questions/problems when I tried to bitbake a recipe in our layer. 1.An error message says: failed on do_rootfs task. Additional message: Computing transaction...error: Can't install smartpm-1.4-1-r9@i586mailto:smartpm-1.4-1-r9@i586: no package provides /usr/bin/udev I tried with two methods: One is to bitbake a recipe in our layer with freescale BSP layer targeting imx6qsabrelite board. The bblayer.conf includes following layers: meta meta-yocto meta-openembedded/meta-oe meta-fsl-arm # From freescale for imx6qsabrelite board meta-fsl-arm-extra # From freescale for imx6qsabrelite board meta-qt5 # Get from https://github.com/meta-qt5/meta-qt5 meta-MM One recipe (We want to bitbake) file in the meta-MM layer looks like following: = IMAGE_FEATURES += splash package-management x11-browser ssh-server-openssh IMAGE_INSTALL += qtbase qtbase-tools qtbase-plugins qtbase-fonts PR=r2 LICENSE = MIT inherit core-image export IMAGE_BASENAME = MM-qt5 = bitbake the recipe without the line in RED above (comment it out), it will succeed, the problem comes when I add this line. My colleague told me to bitbake perl first, and then bitbake the same recipe file again afterwards, the problem goes away. Don't know the reason why??? The other method is: I also tried the same scenario with yocto-bsp layer targeting qemu emulator. I got the same result. 2. When I succeeded in the way my colleague told me, I found the kernel image (uImage/bzImage) is missing in the boot directory of target filesystem. I checked tmp/work/imx6qsabrelite-poky-linux-gnueabi/MM-qt5/1.0-r2/rootfs/boot directory, it was not there. However, bitbake the same recipe without the RED line above, I can find it in both locations. That is really confusing me!!! Same thing I did with qemu emulator, also same result I got. By the way, I will appreciate if some of you can direct me how to bitbake, let me know the status, progress, resources on qt5 package with yocto project. Thanks, Yang Liu VISIT OUR NEW WEB SITE! www.magnetimarelli.com Confidential Notice: This electronic communication - including its attachments - may contain proprietary, confidential and/or legally protected information and documents and is intended to be confidential by the sender and solely for the use of the designated addressee(s) above. Any unauthorized use or disclosure of this communication is prohibited by law. If you are not the intended recipient, be aware that any downloading, copying, disclosure, distribution or use of the contents of the above information is strictly prohibited. If you have received this communication by mistake, please forward the message back to the sender at the email address above, delete the message from all mailboxes and any other electronic storage medium and destroy all copies. Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free. Therefore we do not assure that this message is complete or accurate and we do not accept liability for any errors or omissions or for viruses in the contents of this message ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Qt5
On Thu, May 23, 2013 at 10:51 PM, LIU Yang (MM) yang@magnetimarelli.com wrote: I am first time coming here for help on Yocto project with Qt5, I have two questions/problems when I tried to bitbake a recipe in our layer. sorry to hijack (slightly...) that email, but what is the 'plan' for Qt5 in OE? i don't see Qt5 listed in the yocto 1.5 schedule wiki. so are we going to replace qt4 by qt5 in oe-core? are we going to have them side-by-side? or is it going to live in its own layer? thanks ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2 0/6] Separate org.yocto.remote.utils plugin
I noticed an issue with the patches and reverted the changes. The 2nd patch in the series is corrupted, after applying that patch, the plugin loaded in IDE with an error which is caused by: + 2504c89... Move RSEHelper to a separate plugin Please run some unit testing before sending the patch. Thanks, Jessica -Original Message- From: Zhang, Jessica Sent: Thursday, May 23, 2013 11:44 AM To: Grigoropol, IoanaX; yocto@yoctoproject.org Subject: RE: [yocto] [PATCH v2 0/6] Separate org.yocto.remote.utils plugin Merged to eclipse-poky master. Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Ioana Grigoropol Sent: Monday, May 13, 2013 2:26 AM To: yocto@yoctoproject.org Subject: [yocto] [PATCH v2 0/6] Separate org.yocto.remote.utils plugin - initial commit populate for remote utils common plugin Ioana Grigoropol (6): Initial commit for separate remote utilities plugin Move RSEHelper to a separate plugin Move RemoteShellExec to separate plugin Move ShellSession to org.yocto.remote.utils separate plugin Move CommonHelper to org.yocto.remote.utils separate plugin Move TerminalHandler to org.yocto.remote.utils plugins/org.yocto.remote.utils/.classpath |7 + plugins/org.yocto.remote.utils/.project| 28 ++ .../.settings/org.eclipse.jdt.core.prefs |7 + .../org.yocto.remote.utils/META-INF/MANIFEST.MF| 28 ++ plugins/org.yocto.remote.utils/build.properties|4 + .../org.yocto.remote.utils/resources/ust_tar.sh| 19 + .../org.yocto.remote.utils/resources/yocto_tool.sh | 125 ++ .../org.yocto.remote.utils/resources/yocto_ust.sh | 35 ++ .../src/org/yocto/remote/utils/Activator.java | 62 +++ .../src/org/yocto/remote/utils/CommonHelper.java | 46 +++ .../src/org/yocto/remote/utils/Messages.java | 35 ++ .../src/org/yocto/remote/utils/RSEHelper.java | 344 .../org/yocto/remote/utils/RemoteShellExec.java| 140 +++ .../src/org/yocto/remote/utils/ShellSession.java | 327 +++ .../org/yocto/remote/utils/TerminalHandler.java| 128 ++ .../org.yocto.sdk.remotetools/META-INF/MANIFEST.MF |3 +- .../org.yocto.sdk.remotetools/resources/ust_tar.sh | 19 - .../resources/yocto_tool.sh| 125 -- .../resources/yocto_ust.sh | 35 -- .../org/yocto/sdk/remotetools/CommonHelper.java| 44 -- .../src/org/yocto/sdk/remotetools/RSEHelper.java | 419 .../org/yocto/sdk/remotetools/ShellSession.java| 341 .../yocto/sdk/remotetools/actions/BaseModel.java |4 +- .../sdk/remotetools/actions/BaseSettingDialog.java |2 +- .../sdk/remotetools/actions/DialogHandler.java |1 + .../sdk/remotetools/actions/OprofileModel.java |2 +- .../sdk/remotetools/actions/SystemtapModel.java|2 +- .../actions/SystemtapSettingDialog.java|2 +- .../sdk/remotetools/actions/TerminalHandler.java | 128 -- .../sdk/remotetools/remote/RemoteShellExec.java| 149 --- 30 files changed, 1344 insertions(+), 1267 deletions(-) create mode 100644 plugins/org.yocto.remote.utils/.classpath create mode 100644 plugins/org.yocto.remote.utils/.project create mode 100644 plugins/org.yocto.remote.utils/.settings/org.eclipse.jdt.core.prefs create mode 100644 plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF create mode 100644 plugins/org.yocto.remote.utils/build.properties create mode 100755 plugins/org.yocto.remote.utils/resources/ust_tar.sh create mode 100755 plugins/org.yocto.remote.utils/resources/yocto_tool.sh create mode 100755 plugins/org.yocto.remote.utils/resources/yocto_ust.sh create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/Activator.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommonHelper.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/Messages.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RSEHelper.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RemoteShellExec.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/TerminalHandler.java delete mode 100755 plugins/org.yocto.sdk.remotetools/resources/ust_tar.sh delete mode 100755 plugins/org.yocto.sdk.remotetools/resources/yocto_tool.sh delete mode 100755 plugins/org.yocto.sdk.remotetools/resources/yocto_ust.sh delete mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/CommonHelper.java delete mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/RSEHelper.java delete mode 100644
Re: [yocto] Problem with Python in pre-built SDK
Date: Thu, 23 May 2013 11:37:49 +0100 From: Burton, Ross ross.bur...@intel.com To: Ben Warren ben.war...@spidercloud.com Cc: yocto@yoctoproject.org yocto@yoctoproject.org Subject: Re: [yocto] Problem with Python in pre-built SDK Message-ID: CAJTo0LY8Toagve- 1A0JC7Qg_p5ptp6Q2SOgH3=_+cuxgprr...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On 16 May 2013 22:53, Ben Warren ben.war...@spidercloud.com wrote: I'm having other Yocto problems using the stock Ubuntu x86_64 toolchain, so decided to install one using the instructions in section 2.1.2 (Using a Cross-Toolchain Tarball) of the Yocto Project Application Developer's Guide. What are these other problems? Ubuntu should work fine as a host. ImportError: No module named fcntl So it looks like the Python included with the SDK is crippled or mis- configured: Yeah, the Python we build is split up massively, so clearly the SDK is missing the packages that are needed to run bitbake. But as I said, using our SDK to build is over-complicating things as Ubuntu should work fine. What problems were you seeing? Ross Just in case it matters, this actually bit us pretty badly at one point. We use scons heavily and our typical workflow is to source the toolchain environment script then run scons. Unfortunately, because the environment file adds the toolchain's native usr/bin to the path, scons tries to run with the broken python and you get the above ImportError. We fixed it by just deleting the python binary from the resulting toolchain so that python from the host system is used instead. Not a serious issue, but pretty annoying. Daniel Lazzari Jr. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [eclipse-poky][PATCH 00/13] Completed CMake integration in the Yocto IDE
Hi Atanas, Seems this patch series relies on the previous RFC patches: [yocto] [eclipse-poky][RFCv2 0/7] Introducing a YoctoSDKCMakeProjectNature. Since they were RFC, I didn't apply them and this patch series will report YoctoSDKCMakeProjectNature can't be resolved. Can you send the YoctoSDKCMakeNature as patches not RFC? Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Atanas Gegov Sent: Thursday, May 23, 2013 1:40 AM To: yocto@yoctoproject.org Subject: [yocto] [eclipse-poky][PATCH 00/13] Completed CMake integration in the Yocto IDE From: Atanas Gegov atanas.ge...@bmw-carit.de Hi, this patch series adds a new plugin containing a CMake configure tool, a toolchain and a project type for building CMake projects in the Yocto IDE. The plugin also introduces Hello World templates for C and C++. With this patch series the CMake integration is completed and the CMake projects can be built, debugged etc. as already known from the Autotools-based projects. Cheers, Atanas P.S: This patch series requires the already discussed patch series [eclipse-poky][RFCv2 0/7] Introducing a YoctoSDKCMakeProjectNature. Atanas Gegov (13): plugins/cmake: Added an empty CMake integration plugin plugins/cmake: Defined CMake tool with options plugins/sdk.ide: Added a method to get project environment plugins/cmake: Preparing a configure Job plugins/cmake: Added run method to configure Job plugins/cmake: Added a Makefile generator plugins/cmake: Added the generation of toolchain.cmake plugins/cmake: Defined the building toolchain plugins/cmake: Added a new category for CMake projects plugins/cmake: Connect toolchain and new project category plugins/cmake: Added CMake template projects plugins/sdk.ide: Adapted RemoteDebugLauncher for CMake projects features/sdk: Added CMake plugin to sdk feature features/org.yocto.sdk/feature.xml |6 + plugins/org.yocto.cmake.managedbuilder/.classpath |7 + plugins/org.yocto.cmake.managedbuilder/.project| 28 ++ .../.settings/org.eclipse.jdt.core.prefs |8 + .../META-INF/MANIFEST.MF | 16 ++ .../OSGI-INF/l10n/bundle.properties| 40 +++ .../build.properties |7 + plugins/org.yocto.cmake.managedbuilder/plugin.xml | 283 .../org/yocto/cmake/managedbuilder/Activator.java | 50 .../YoctoCMakeMakefileGenerator.java | 281 +++ .../cmake/managedbuilder/YoctoCMakeMessages.java | 57 .../managedbuilder/YoctoCMakeMessages.properties | 27 ++ .../managedbuilder/job/ExecuteConfigureJob.java| 149 +++ .../cmake/managedbuilder/util/ConsoleUtility.java | 49 .../cmake/managedbuilder/util/SystemProcess.java | 118 .../HelloWorldCCMakeProject/src/CMakeLists.txt | 34 +++ .../HelloWorldCCMakeProject/src/main.c | 21 ++ .../HelloWorldCCMakeProject/template.properties| 31 +++ .../HelloWorldCCMakeProject/template.xml | 61 + .../HelloWorldCPPCMakeProject/src/CMakeLists.txt | 34 +++ .../HelloWorldCPPCMakeProject/src/main.cpp | 21 ++ .../HelloWorldCPPCMakeProject/template.properties | 31 +++ .../HelloWorldCPPCMakeProject/template.xml | 61 + .../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 29 +- 24 files changed, 1445 insertions(+), 4 deletions(-) create mode 100644 plugins/org.yocto.cmake.managedbuilder/.classpath create mode 100644 plugins/org.yocto.cmake.managedbuilder/.project create mode 100644 plugins/org.yocto.cmake.managedbuilder/.settings/org.eclipse.jdt.core.prefs create mode 100644 plugins/org.yocto.cmake.managedbuilder/META-INF/MANIFEST.MF create mode 100644 plugins/org.yocto.cmake.managedbuilder/OSGI-INF/l10n/bundle.properties create mode 100644 plugins/org.yocto.cmake.managedbuilder/build.properties create mode 100644 plugins/org.yocto.cmake.managedbuilder/plugin.xml create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/Activator.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMakefileGenerator.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMessages.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/YoctoCMakeMessages.properties create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/job/ExecuteConfigureJob.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/util/ConsoleUtility.java create mode 100644 plugins/org.yocto.cmake.managedbuilder/src/org/yocto/cmake/managedbuilder/util/SystemProcess.java create mode 100644
[yocto] Improper tags for 1.3.2
All, This morning, in preparation for the 1.3.2 point release, I accidentally created tags named danny-8.2.0 (instead of danny-8.0.2) in the following repos: eclipse-poky poky meta-qt3 meta-intel I am removing these tags. If you've updated your local copy of one of these repos within the past few hours please remove your local tag: git tag -d danny-8.2.0 Thank you and sorry for the inconvenience. -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ANNOUNCEMENT] Yocto Project 1.3.2 danny released.
Hello, The latest point release of the Yocto Project danny release, 1.3.2, is now available for download at: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/poky-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/poky-danny-8.0.2.tar.gz Thanks go out to everyone for all their hard work during this release! Sincerely, Elizabeth Flanagan Yocto Build and Release elizabeth.flana...@intel.com yocto-1.3.2 Errata Release Name: poky-danny-8.0.2 Branch: danny Tag: danny-8.0.2 Hash: e52a74755b72038def2f093d18212d033d3d862d md5: 9fd0cdda96b9927958371ff2762bf293 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/poky-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/poky-danny-8.0.2.tar.gz Release Name: meta-intel-danny-8.0.2 Branch: danny Tag: danny-8.0.2 Hash: d44f005338012cc790122b2ab08a29c0e0e7 md5: 8073ec8d84bb626a4c55e8c4d763dd09 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/meta-intel-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/meta-intel-danny-8.0.2.tar.gz Release Name: eclipse-poky-danny-8.0.2 Branch: danny Tag: danny-8.0.2 Hash: ae28375759e6c9a6eef64f74b61d95e1cb00783d md5: 120cb5215f073905e02e44e079c5d78c Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/eclipse-poky-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/eclipse-poky-danny-8.0.2.tar.gz Release Name: meta-qt3-danny-8.0.2 Branch: danny Tag: danny-8.0.2 Hash: c86fb1727ae09526c442ec29fffde3f010aa70eb md5: 466c7fce61c655d274b0e0e1d2b8483d Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/meta-qt3-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/meta-qt3-danny-8.0.2.tar.gz Notable Fixes - Improved reliability in sanity testing - Improved multilib support - Numerous toolchain and sdk packaging fixes Security fixes CVE-2012-6085 (gupnp) CVE-2010-5107 (openssh) CVE-2012-6329 (perl) CVE-2013-1667 (perl) Known Issues - Depending on configuration and existing sstate, images may try to install both lttng-ust and lttng2-ust into an image, which will fail. To work around this, bitbake -ccleansstate all of the lttng recipes. Bug Fixes 2918: lib64-core-image-sato-sdk fails due to do_rootfs issue 3069: perl File::Glob module is broken. 3100: autoreconf run failed on x86-64 gmae-toolchain 3325: nativesdk-ncurses 5.9: files were installed but not shipped 3338: iptables-1.4.15: autoreconf run failed on gmae-toolchain 3389: bitbake lib64-core-image-sato fails due to nothing PROVIDES errors 3401: standalone toolchain should notify the user if the target install dir of SDK is one already used 3640: sanity.bbclass sometimes failing to find saved_tmpdir when tmp-eglibc was deleted 3745: [Test Case 169] Bitbake remake/remake-native check 3839: [Test Case 378] Relocatable SDK - C - build Hello World GTK C Autotols Project 3935: beagleboard/routerstation/mpc8315e: abnormal filesystem-related messages in dmesg when plugging a usb stick 3951: perf doesn't build with core-image-minimal 3983: [danny 1.3.1] Invalid symbolic link file in adt_installer.tar.bz2 3984: iptables-1.4.15: autoreconf run fails on 1.3.1 4010: bitbake ignores PRservice error 4014: Regarding Licensing of mbsalign.c available in util-linux-2.21.2 version (Yocto-1.3-Danny) 4470: Powertop fails do_compile on nightly-x86-lsb -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-announce] [ANNOUNCEMENT] Yocto Project 1.3.2 danny released.
Thank you, Beth and Ross. And congratulations to the team on the release! Song -Original Message- From: yocto-announce-boun...@yoctoproject.org [mailto:yocto-announce-boun...@yoctoproject.org] On Behalf Of Flanagan, Elizabeth Sent: Thursday, May 23, 2013 4:21 PM To: yocto@yoctoproject.org; yocto-annou...@yoctoproject.org Subject: [yocto-announce] [ANNOUNCEMENT] Yocto Project 1.3.2 danny released. Hello, The latest point release of the Yocto Project danny release, 1.3.2, is now available for download at: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/poky-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/poky-danny-8.0.2.tar.gz Thanks go out to everyone for all their hard work during this release! Sincerely, Elizabeth Flanagan Yocto Build and Release elizabeth.flana...@intel.com yocto-1.3.2 Errata Release Name: poky-danny-8.0.2 Branch: danny Tag: danny-8.0.2 Hash: e52a74755b72038def2f093d18212d033d3d862d md5: 9fd0cdda96b9927958371ff2762bf293 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/poky-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/poky-danny-8.0.2.tar.gz Release Name: meta-intel-danny-8.0.2 Branch: danny Tag: danny-8.0.2 Hash: d44f005338012cc790122b2ab08a29c0e0e7 md5: 8073ec8d84bb626a4c55e8c4d763dd09 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/meta-intel-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/meta-intel-danny-8.0.2.tar.gz Release Name: eclipse-poky-danny-8.0.2 Branch: danny Tag: danny-8.0.2 Hash: ae28375759e6c9a6eef64f74b61d95e1cb00783d md5: 120cb5215f073905e02e44e079c5d78c Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/eclipse-poky-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/eclipse-poky-danny-8.0.2.tar.gz Release Name: meta-qt3-danny-8.0.2 Branch: danny Tag: danny-8.0.2 Hash: c86fb1727ae09526c442ec29fffde3f010aa70eb md5: 466c7fce61c655d274b0e0e1d2b8483d Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3.2/meta-qt3-danny-8.0.2.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-1.3.2/meta-qt3-danny-8.0.2.tar.gz Notable Fixes - Improved reliability in sanity testing - Improved multilib support - Numerous toolchain and sdk packaging fixes Security fixes CVE-2012-6085 (gupnp) CVE-2010-5107 (openssh) CVE-2012-6329 (perl) CVE-2013-1667 (perl) Known Issues - Depending on configuration and existing sstate, images may try to install both lttng-ust and lttng2-ust into an image, which will fail. To work around this, bitbake -ccleansstate all of the lttng recipes. Bug Fixes 2918: lib64-core-image-sato-sdk fails due to do_rootfs issue 3069: perl File::Glob module is broken. 3100: autoreconf run failed on x86-64 gmae-toolchain 3325: nativesdk-ncurses 5.9: files were installed but not shipped 3338: iptables-1.4.15: autoreconf run failed on gmae-toolchain 3389: bitbake lib64-core-image-sato fails due to nothing PROVIDES errors 3401: standalone toolchain should notify the user if the target install dir of SDK is one already used 3640: sanity.bbclass sometimes failing to find saved_tmpdir when tmp-eglibc was deleted 3745: [Test Case 169] Bitbake remake/remake-native check 3839: [Test Case 378] Relocatable SDK - C - build Hello World GTK C Autotols Project 3935: beagleboard/routerstation/mpc8315e: abnormal filesystem-related messages in dmesg when plugging a usb stick 3951: perf doesn't build with core-image-minimal 3983: [danny 1.3.1] Invalid symbolic link file in adt_installer.tar.bz2 3984: iptables-1.4.15: autoreconf run fails on 1.3.1 4010: bitbake ignores PRservice error 4014: Regarding Licensing of mbsalign.c available in util-linux-2.21.2 version (Yocto-1.3-Danny) 4470: Powertop fails do_compile on nightly-x86-lsb -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto-announce mailing list yocto-annou...@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto-announce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External-Sourcery-Toolchain Related Issue
On Thu, May 23, 2013 at 12:39 AM, Rohit2 Jindal
rohit2.jin...@aricent.comwrote:
I want to install my existing Toolchain to Yocto Sysroot bypassing default
yocto toolchain functionality.
** **
My requirements are
** **
1I will download toolchain from my git source ie tar file.
2I just want to install this toolchain to tmp/sysroot folder in build
directory skipping compilation step.
** **
** **
Steps implemented
** **
1 SRC_URI = file:///home/toolchains_bin.tar
2 TCMODE=external-csl
3 EXTERNAL_TOOLCHAIN =
/home/yocto/poky/build/tmp/work/mips64-poky-linux/external-sourcery-toolchain/GCC-r8/toolchains_bin/mipscross/linux
4CSL_TARGET_SYS_mips64 = ${TARGET_ARCH}${TARGET_TC_VENDOR}-${TCTYPE}
5CSL_TARGET_SYS = ${TARGET_ARCH}${TARGET_TC_VENDOR}-${TCTYPE}
6 TARGET_PREFIX = ${CSL_TARGET_SYS_mips64}-
The sourcery toolchain recipe pulls files from a codesourcery / mentor
graphics Sourcery G++ toolchain installed at the EXTERNAL_TOOLCHAIN path.
That SRC_URI will not do anything, and it expects the compiler to be
available at parse time. Basically, the tcmode and recipe for sourcery is
designed for a particular toolchain, not any random one, and is not
structured at this time to allow extraction of a toolchain binary tarball.
You'd have to customize / create your own based on the existing bits, using
them as examples.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-xilinx moved to meta-xilinx-community
Hi, The existing meta-xilinx repo has moved to meta-xilinx-community http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx-community/ This layer will contain community support for the Xilinx platforms, including legacy boards (ML507) and other soft-processor architectures. This paves the way for an officially supported meta-xilinx layer, the details of which will be officially announced by Xilinx. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
