[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-architecture
Subject:    Re: [Openembedded-architecture] OEDEM - Setup program
From:       Jan-Simon =?ISO-8859-1?Q?M=F6ller?= <dl9pf () gmx ! de>
Date:       2017-03-07 16:32:13
Message-ID: 2579900.9ucux9rhJD () elrond
[Download RAW message or body]

Its on my list, but I need to fix the current layer dependencies ;) to make =

it work. Stay tuned.

Best,
Jan-Simon

Am Dienstag, 7. M=E4rz 2017, 11:25:17 schrieb Philip Balister:
> Also, we are interested in hearing about success (and failure) stories
> with this tool.
> =

> Philip
> =

> On 03/07/2017 09:45 AM, Mark Hatle wrote:
> > One more follow up on this.  The primary thing that was preventing peop=
le
> > form using the setup program was that the OpenEmbedded layer index was
> > missing many of the indexed distribution entries.
> > =

> > This has now been corrected.
> > =

> > master, morty and krogoth have been properly indexed.  If anything does
> > not work at this point please let me know, as all of the pieces are now
> > in place to successfully use this.
> > =

> > --Mark
> > =

> > On 11/16/16 4:12 PM, Mark Hatle wrote:
> >> The setup program that was demonstrated at OEDEM is now available.
> >> =

> >> https://github.com/Wind-River/wr-lx-setup
> >> =

> >> My expectation is that if OpenEmbedded decided to take ownership of th=
is
> >> project that they will fork a copy of this, and then I will stop
> >> development of this github project.  If OpenEmbedded does fork the
> >> project, a suitable name should be selected at that time.
> >> =

> >> =

> >> To begin, the setup program uses the contents from the layer index.  So
> >> the
> >> results are only going to be as good as the layer index you are using. =

> >> In
> >> addition, the current layer index does not yet have distro indexing. =

> >> This is available in the paule/django18 branch, but has not yet gone
> >> into the production version.  When the setup program uses an index
> >> without any distribution information, it simply adds a single 'nodistr=
o'
> >> entry for OpenEmbedded.
> >> =

> >> Once the setup program loads the layer index, it will use the users
> >> settings to discover which layers are necessary to construct the
> >> project.  It creates a repo .xml file and uses repo to manage and pull
> >> down the layers.  The system will also construct/copy various sample
> >> configuration, README and other files.
> >> =

> >> =

> >> Below are some basic usage instructions.  See the README.md file, but
> >> I've
> >> duplicated some of the contents below to give you an idea of the
> >> workflow.
> >> =

> >> To create a new project.  The minimal workflow becomes:
> >> =

> >> mkdir my-project
> >> cd my-project
> >> git clone git://github.com/Wind-River/wr-lx-setup setup
> >> ./setup/setup.sh --machine qemux86-64
> >> =

> >> At this point the program will contact the layer index and determine =

what
> >> provides the BSP qemux86-64 and will construct a system that includes
> >> this BSP.
> >> =

> >> This should look similar to what you are used to by manually cloning
> >> oe-core and bitbake:
> >> =

> >> bitbake  default.xml  meta               oe-init-build-env-memres =

> >> scripts
> >> config   layers       oe-init-build-env  README                    set=
up
> >> =

> >> You'll see the addition of a 'default.xml' file, a layers directory, a
> >> config directory, a customized README and of course the 'setup' progra=
m.
> >>   All layers and other components downloaded end up in the 'layers'
> >> directory.  Default configurations and log information go in the
> >> 'config' directory.  Only specific files are symlinked to the root
> >> (OpenEmbedded and the related bitbake of course.)
> >> =

> >> =

> >> Now for the more advanced information.  This is how everything is
> >> controlled.
> >> =

> >> First the shell script wrapper, setup.sh, is responsible for making the
> >> current directory into a git tree, identifying the branch the setup
> >> program was run from, and has the ability to run various extension
> >> scripts.
> >> =

> >> The setup program then exports certain information, such as the base
> >> download directory and branch and calls the bin/setup.py program.  (If
> >> you use --help and do not have python3 available it will use a special
> >> python version to display basic help.)
> >> =

> >> The setup.py can replace a special '#BASE_URL#' field when processing
> >> URLs with the url that the setup program was loaded from.  (This is VE=
RY
> >> useful when handling internal mirrors.)  The branch requested from the
> >> layer index is the same branch as the setup program is running from by
> >> default as well.  This allows you to have special configuration files =
or
> >> other files per branch.
> >> =

> >> Below is a series of files or directories that are used by the setup
> >> program to specify various defaults, or files that get put into the
> >> constructed project.>> =

> >> bin/settings.py:
> >>   This file controls the defaults for the setup program.  Including the
> >>   location>> =

> >> of the layer index, branch settings, special 'search replace' =

operations,
> >> default values, etc.   Take a look at this file.  If you have any
> >> questions let me know.
> >> =

> >> As mentioned above, the #BASE_URL# is a magic flag..  if you want to u=
se
> >> this on a live layer-index, you can put in a manual search/replace
> >> operation.  This only affects repository URLs BTW.
> >> =

> >> data/samples:
> >>   This directory contains sample files for the bblayers.conf, =

local.conf,
> >> =

> >> conf-notes, README and a special README-MIRROR.
> >> =

> >>   Each of these files is processed when copying into the constructed
> >>   project.
> >>   =

> >>   Special key works can be used to replace contents with dynamic conte=
nt
> >>   based>> =

> >> on the configured:
> >>     ####LAYERS#### - replace with each layer, format is for =

bblayers.conf
> >>     =

> >>     ####SETUP_ARGS#### -- replace with the current arguments to setup
> >>     =

> >>     ####MACHINES##### -- replace with a list of each machine available =

in
> >>     the
> >> =

> >> current layers
> >> =

> >>     ####DEFAULTMACHINE#### -- replace with the -first- machine in the
> >>     list
> >>     =

> >>     ####DISTROS#### -- replace with a list of each distro available in
> >>     the
> >> =

> >> current layers (required layer index support)
> >> =

> >>     ####DEFAULTDISTRO#### --- replace with the -first- distro in the =

list
> >> =

> >> data/xml:
> >>   There are two types of files that can be in this set, .inc and .xml. =

> >>   All
> >> =

> >> files are named 'layer name' (per the layer index) with the appropriate
> >> suffix. A special 'bitbake' one is implemented as well.
> >> =

> >> The .inc files are included inline in the project element for the laye=
r. =

> >> This is the mechanism to add symlinks or other repo tags that must be
> >> inline with in a 'project' tag.
> >> =

> >> The .xml files are included -after- the close of the project tag for t=
he
> >> layer. This can be used to include additional (non-layer) components
> >> into the generated repo default.xml file when a specific layer is
> >> included.
> >> =

> >> =

> >> Advanced features:
> >> =

> >> There is a --mirror option to the setup program.  This will take the
> >> configuration you specified and create a local 'repo mirror' of the
> >> contents, as well as a copy of the layer index (only the pieces that
> >> affect the mirror) and any corresponding XML fragments.
> >> =

> >> The mirror allows you to start new projects from the mirror without
> >> having to contact the upstream layer index or original sources.  This
> >> can also be useful to share a specific configuration with others,
> >> especially if you want to curate a specifically supported set of layer=
s.
> >> =

> >> The contents of the mirror can also be shared on a local git server,
> >> making it even easier to share.
> >> =

> >> In many environments local git servers can not handle sub directories. =

> >> (github, stash, etc..)  So there is a 'flatten_mirror.py' command in
> >> bin.. When run from a mirror project, it will create a flattened tree
> >> that may be easier for some people to share on a git server (or other
> >> resources.)
> >> =

> >> =

> >> There are other features, but overall the program isn't very large.  I=
'm
> >> happy to answer any questions related to this.
> >> =

> >> --Mark
> >> _______________________________________________
> >> Openembedded-architecture mailing list
> >> Openembedded-architecture@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-architectu=
re
> > =

> > _______________________________________________
> > Openembedded-architecture mailing list
> > Openembedded-architecture@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> =

> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

-- =

--
Jan-Simon M=F6ller
dl9pf@gmx.de
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
[prev in list] [next in list] [prev in thread] [next in thread]