All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <koen@dominion.thruhere.net>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: yocto <yocto@yoctoproject.org>, poky <poky@yoctoproject.org>
Subject: Re: [poky] Major feature changes for the next release - merging very soon
Date: Tue, 25 Jan 2011 19:34:04 +0100	[thread overview]
Message-ID: <F4686931-067A-4564-BDD3-073B8F1BB435@dominion.thruhere.net> (raw)
In-Reply-To: <1295963829.14388.49564.camel@rex>


Op 25 jan 2011, om 14:57 heeft Richard Purdie het volgende geschreven:

> As has been mentioned in other emails we're working on some major
> enhancements for the next release. Several components of these are now
> ready for merging to the master branch. These include:
> 
> * Rework of the compiler bootstrap process
> 
> If you've ever tried to run "bitbake eglibc -c clean;bitbake eglibc" or
> any of the gcc components you'll have run into issues with the compiler
> bootstrap process overwriting files. This also causes problems for
> sstate as it doesn't get on well with two sstate archives providing the
> same file.
> 
> The changes we have queued split the intermediate components into a
> separate sysroot so no files are overwritten and the whole process is
> less fragile and more robust. Each gcc-cross step (initial, intermediate
> and final) also stage binaries in separate locations.
> 
> * Changes to sysroot structure
> 
> We now support creating a sysroot per machine target rather than the
> original multimachine approach we have used. This means packages with an
> "all" architecture can be safely installed into the sysroot and used
> correctly fixing bugs in that area and it also allows machines like
> emenlow which have separate graphics components to build and work
> correctly yet be able to share builds with other machines like atom-pc.
> 
> If you change machine and the machine you change to shares a core
> architecture with a previous build, the components from that previous
> build will be used to construct a new sysroot using the sstate prebuilt
> packages.
> 
> The branch I'm planning to merge very soon with these features is:
> 
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rpurdie/tt-bootstrap

For a single machine:

NOTE: package console-image-1.0-r0: task do_rm_work_all: Succeeded


Now building it incrementally for a different machine


WARNING: multiple messages have this Message-ID (diff)
From: Koen Kooi <koen@dominion.thruhere.net>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: yocto <yocto@yoctoproject.org>, poky <poky@yoctoproject.org>
Subject: Re: Major feature changes for the next release - merging very soon
Date: Tue, 25 Jan 2011 19:34:04 +0100	[thread overview]
Message-ID: <F4686931-067A-4564-BDD3-073B8F1BB435@dominion.thruhere.net> (raw)
In-Reply-To: <1295963829.14388.49564.camel@rex>


Op 25 jan 2011, om 14:57 heeft Richard Purdie het volgende geschreven:

> As has been mentioned in other emails we're working on some major
> enhancements for the next release. Several components of these are now
> ready for merging to the master branch. These include:
> 
> * Rework of the compiler bootstrap process
> 
> If you've ever tried to run "bitbake eglibc -c clean;bitbake eglibc" or
> any of the gcc components you'll have run into issues with the compiler
> bootstrap process overwriting files. This also causes problems for
> sstate as it doesn't get on well with two sstate archives providing the
> same file.
> 
> The changes we have queued split the intermediate components into a
> separate sysroot so no files are overwritten and the whole process is
> less fragile and more robust. Each gcc-cross step (initial, intermediate
> and final) also stage binaries in separate locations.
> 
> * Changes to sysroot structure
> 
> We now support creating a sysroot per machine target rather than the
> original multimachine approach we have used. This means packages with an
> "all" architecture can be safely installed into the sysroot and used
> correctly fixing bugs in that area and it also allows machines like
> emenlow which have separate graphics components to build and work
> correctly yet be able to share builds with other machines like atom-pc.
> 
> If you change machine and the machine you change to shares a core
> architecture with a previous build, the components from that previous
> build will be used to construct a new sysroot using the sstate prebuilt
> packages.
> 
> The branch I'm planning to merge very soon with these features is:
> 
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rpurdie/tt-bootstrap

For a single machine:

NOTE: package console-image-1.0-r0: task do_rm_work_all: Succeeded


Now building it incrementally for a different machine


  parent reply	other threads:[~2011-01-25 18:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-25 13:57 Major feature changes for the next release - merging very soon Richard Purdie
2011-01-25 14:19 ` [poky] " Koen Kooi
2011-01-25 14:19   ` Koen Kooi
2011-01-25 18:34 ` Koen Kooi [this message]
2011-01-25 18:34   ` Koen Kooi
2011-01-25 19:18   ` [poky] " Koen Kooi
2011-01-25 19:18     ` Koen Kooi
2011-01-25 19:41     ` [poky] " Koen Kooi
2011-01-25 19:41       ` Koen Kooi
2011-01-25 21:35       ` [poky] " Richard Purdie
2011-01-25 21:35         ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F4686931-067A-4564-BDD3-073B8F1BB435@dominion.thruhere.net \
    --to=koen@dominion.thruhere.net \
    --cc=poky@yoctoproject.org \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.