[PATCH] Making using layers even friendlier

[PATCH] Making using layers even friendlier

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

I'm building poky for a number of unique platforms which I
want to keep logically separate.  By using the new BBLAYERS
support, this is working out quite well.

However, I find it cumbersome to start a new build for a given
platform.  This is because conf/local.conf and conf/bblayers.conf
need to be tailored for that platform.  In particular, the file
conf/bblayers.conf needs to be modified to incorporate the
meta layers used by the given platform.

By incorporating the attached patch, this can now be done easily
on the initial build tree setup.  Just run something like this:
   % POKYCONF=meta-board1/conf . <POKYBASE>/poky-init-build-env my_build_tree
As the build tree is set up, the files from <POKYBASE>/meta-board1/conf
will be used to populate the <BUILD>/conf directory.  These can then
be adjusted as necessary.  The patch allows for the provided config
files to be either <POKYBASE> relative or absolute, allowing even
more flexibility.

Comments?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: 0001-Allow-the-environment-variable-POKYCONF-to-provide-t.patch --]
[-- Type: text/plain, Size: 1580 bytes --]

From 2323932145370e2fea2a427c3c493d04b043981b Mon Sep 17 00:00:00 2001
From: Gary Thomas <gary@mlbassoc.com>
Date: Wed, 8 Dec 2010 05:59:09 -0700
Subject: [PATCH] Allow the environment variable POKYCONF to provide the basis for the working "conf" directory.

By using the POKYCONF variable, a meta layer can provide the basic setup for files to
be used during a build.  This is similar to the default values stored in the main meta
tree, .../meta/conf/local.conf.sample, etc

Signed-off-by: Gary Thomas <gary@mlbassoc.com>
---
 scripts/poky-env-internal |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/scripts/poky-env-internal b/scripts/poky-env-internal
index 5b206ed..c8b39c9 100755
--- a/scripts/poky-env-internal
+++ b/scripts/poky-env-internal
@@ -58,6 +58,24 @@ if ! (test -d "$BITBAKEDIR" && test -d "$BUILDDIR"); then
     return
 fi
 
+# 
+# $POKYCONF can point to a directory for the template local.conf & bblayers.conf
+#
+if [ "x" != "x$POKYCONF" ]; then
+    if ! (test -d "$POKYCONF"); then
+	# Allow POKYCONF=meta-xyz/conf as a shortcut
+	if [ -d "$OEROOT/$POKYCONF" ]; then
+	    POKYCONF="$OEROOT/$POKYCONF"
+	fi
+	if ! (test -d "$POKYCONF"); then
+	    echo >&2 "Error: '$POKYCONF' must be a directory containing local.conf & bblayers.conf"
+	    return
+	fi
+    fi
+    POKYLAYERCONF="$POKYCONF/bblayers.conf"
+    POKYLOCALCONF="$POKYCONF/local.conf"
+fi
+
 if [ "x" = "x$POKYLOCALCONF" ]; then
     POKYLOCALCONF="$OEROOT/meta/conf/local.conf.sample"
 fi
-- 
1.7.2.3

Re: [PATCH] Making using layers even friendlier

[Richard Purdie]

On Wed, 2010-12-08 at 06:11 -0700, Gary Thomas wrote:
> I'm building poky for a number of unique platforms which I
> want to keep logically separate.  By using the new BBLAYERS
> support, this is working out quite well.
> 
> However, I find it cumbersome to start a new build for a given
> platform.  This is because conf/local.conf and conf/bblayers.conf
> need to be tailored for that platform.  In particular, the file
> conf/bblayers.conf needs to be modified to incorporate the
> meta layers used by the given platform.
> 
> By incorporating the attached patch, this can now be done easily
> on the initial build tree setup.  Just run something like this:
>    % POKYCONF=meta-board1/conf . <POKYBASE>/poky-init-build-env my_build_tree
> As the build tree is set up, the files from <POKYBASE>/meta-board1/conf
> will be used to populate the <BUILD>/conf directory.  These can then
> be adjusted as necessary.  The patch allows for the provided config
> files to be either <POKYBASE> relative or absolute, allowing even
> more flexibility.
> 
> Comments?

I think its a reasonable idea and I've added it to master.

Cheers,

Richard