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

List:       openembedded-architecture
Subject:    Re: [Openembedded-architecture] OEDEM - Setup program
From:       Mark Hatle <mark.hatle () windriver ! com>
Date:       2016-10-18 21:32:59
Message-ID: cd6b2266-e6fb-e0a5-e6ad-1bd00b19586a () windriver ! com
[Download RAW message or body]

On 10/18/16 4:18 PM, Trevor Woerner wrote:
> A number of people/projects have been bandying about a number of solutions to
> this same question for a couple years now [1].
> 
> In other words: several people/projects have independently come to the
> conclusion that some tool was needed to help people put together and clone
> various layers. This tool would come before bitbake in a user's workflow.
> 
> I'm happy to see Mark's tool come to light. In my opinion, it would be nice to
> see the community hone in on one tool rather than continue their separate
> paths. This would happen faster if the tool came under the project's umbrella
> (alongside the other tools like bitbake, toaster, crops, devtool, etc). Also,
> a common tool would get better documentation, better support, and is more
> likely to be better maintained over time. But we have to make sure it's a tool
> the community is going to get behind and support!
> 
> From what I can tell all these tools have the same goals in common. How they
> differ is based on:
> 
> 1) whether they use a repo manifest or simply clone layers "by hand"
> 
> 2) whether they interrogate the layerindex for layer information or simply
>    grep through whatever layers the script finds "beneath" it in the directory
>    structure (which are pulled/cloned from earlier in the script)
> 
> 3) whether the tool uses a quasi-graphic interface (dialog/whiptail) or the
>    plain cmdline (some tools let you choose or will look for one, fall back,
>    look for another, then fall back to the cmdline if "graphical" options
>    aren't available)
> 
> A tool that uses repo introduces another tool (and possibly another workflow)
> for the user to learn (i.e. Android's repo). But it allows the creators much
> better control over the possibility of success for the build. In other words,
> if I know that <these> checkouts of <those> repositories are going to work
> well together then I can just pin <those> specific repositories at <these>
> specific HEADs, and everything should work.
> 
> A tool that interrogates the layerindex allows the creators of the tool to not
> have to guarantee any specific build or MACHINE. In other words it becomes
> more flexible. A tool that uses the layerindex is less likely to die from
> bitrot; if a new MACHINE/layer/distro/whatever is added to the layerindex in
> the future, no changes are needed to the tool to take advantage of this new
> thing. But the success of the build relies much more heavily on the quality of
> the metadata in the layerindex.
> 
> A tool that uses the repo method needs more maintenance as time goes on. A
> tool that simply pulls its information from the layerindex only needs to be
> updated if the layerindex's REST API changes.
> 
> A tool that relies exclusively on the layerindex ignores local layers. If the
> user has their own in-house custom layers, there needs to be a way to pull
> them into the layer setup too (although these could be added later by hand).
> 
> What ends up happening is that the repo-based tools lend themselves to
> projects that are trying to build distributions for a given (static) set of
> boards/MACHINEs. The layerindex tools lend themselves to situations where a
> person just wants to create an image for a specific board.
> 
> In the end they're all attempts at creating a cmdline version of toaster ;-)

And this last point is important.  I did not want to do that.  The act of
configuration and setup of a specific build directory should still be handled by
existing components, tools, etc.  The only thing the 'chef' can do is help fill
out sample files by listing available resources that the user (or another
program) can use for configuration.

> 
> From what I can tell, Mark's tool doesn't use repo, gets its layer information

To clarify, the program is NOT tied to repo, HOWEVER it does currently use repo
-- in that it constructs a repo default.xml file, runs 'repo init' and uses
'repo sync'.  But this is integration is intentionally kept 'light' -- based on
comments from last week OEDEM and others, people want different things.  I think
one of the first logical enhancements would be to abstract the repo pieces of
this to allow someone to plug in their own mechanism...  repo just seemed to be
the more common denominator over the past few years and the various research
I've done.

> from the layerindex, and doesn't use any fancy "graphics" tool. What's also
> interesting about Mark's tool is that it only tries to be a layer setup tool;
> most of the other tools also try to help the user configure their build after
> the layer's are chosen and cloned.

Once the 'chef' is complete acquiring the ingredients... then it's up to the
developer to run the oe-init-build-env and configure everything in their build.
So devtool add-layer, modifying local.conf, running toaster, etc, etc are all
still valid workflows.

--Mark

> 
> ...just my 2 cents...
> 
> 
> 
> 
> [1] This is the history as I know it, I'm sure others can chime in with more
> details:
> 
> - a long time ago angstrom used a custom script to pull its layers together
>   (pre-2011?) (setup-scripts?)
> - the Freescale community created their "setup-environment" script (2012):
>   https://github.com/Freescale/fsl-community-bsp-platform
> - I created my own "oe-layerindex-config" (2015)
>   https://github.com/twoerner/oe-layerindex-config
>   which was a proof-of-concept tool to use "dialog" to allow a user to select
>   layers from the layerindex and configure for a build
> - some Linaro people were interested in some of the ideas from
>   oe-layerindex-config (dialog) combined with angstrom's setup-scripts but
>   weren't interested in pulling metadata from layerindex so they created the
>   oe-rpb-manifest https://github.com/96boards/oe-rpb-manifest
>   (this comes from angstrom's scripts, so in the git history it is old, but in
>   reality the RPB stuff is from 2015)
> - I liked the oe-rpb-manifest but wanted to add the ability to use any of
>   dialog, whiptail, or the cmdline so I created oe-repo-config (2015)
> _______________________________________________
> 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
[prev in list] [next in list] [prev in thread] [next in thread]