Bug 7880

*** Bug 8022 has been marked as a duplicate of this bug. ***

Proposed intermediate fix

- new tmp dir for project
- On release change rm tmp dir

*** Bug 8204 has been marked as a duplicate of this bug. ***

tmp needs to be :tmp_toaster_<release>
unfortunately we also need to fix buildhistory
it needs to be buildhistory_toaster_<release>

I had a brief conversation with Paul Eggleton about this issue, and he believes that projects should not share anything apart from sstate-cache. This effectively means we should have a build directory per project, and an option to share the sstate directory across projects. In Paul's words: 

"we would probably be asking if you want the sstate-cache shared when creating the project and then set it according to that checkbox"

As a response to Brian's mention of buildhistory above, that issue goes away if we keep the build directories separate, because then the default path still works.

brian concurs.  I think Pauls approach is cleaner and may solve several issues at once. will try out an implementation.

(In reply to comment #7)
> brian concurs.  I think Pauls approach is cleaner and may solve several
> issues at once. will try out an implementation.

If we go for this, we'll need to add the sstate-dir option somewhere in the UI. Marking the issue as needing design.

(In reply to comment #8)
> (In reply to comment #7)
> > brian concurs.  I think Pauls approach is cleaner and may solve several
> > issues at once. will try out an implementation.
> 
> If we go for this, we'll need to add the sstate-dir option somewhere in the
> UI. Marking the issue as needing design.

There is now design for this: check the design document attached to bug 8422

Something else has occurred to me: what will be the naming scheme for the build directories for each project? If the plan is using the project name, then we'll need to make sure that we enforce a unique name policy for projects in Toaster. Right now, you can create more than one project with the same name, as reported by bug 7005.

We'll need to validate the project name when you are creating the project, and show you a little message if another project with the same name exists in the Toaster instance. I'll come up with something.

Until this gets fixed, the workaround is to stick with one release for a given instance of toaster.  If you really need to switch releases, you can run one instance of toaster on port 8000 (the default) in dir /home/me/toaster1/ and another on port 8001 in dir /home/me/toaster2.

To set the port when starting toaster do :
. /home/me/poky/bitbake/bin/toaster webport=8001 start
If it's not set, it will default to port 8000.

seems that the issue still exists in YP 2.1_M2.rc1
master/3d2c0f5902cacf9d8544bf263b51ef0dd1a7218c

I'm not sure I understand what needs to be done here.

User has to initialize build environment *before* starting toaster. Specifying build directory is part of this. Does it mean that this is documentation issue? Should we suggest user to use non-default build directory?

So the problem is that although Toaster happily allows you to select different releases of the Yocto Project, there is no connection between the release you select and the build directory used for the builds. As a result, the same build directory is used for different releases, and that causes build failures. 

(In reply to comment #13)
> I'm not sure I understand what needs to be done here.
> 
> User has to initialize build environment *before* starting toaster.
> Specifying build directory is part of this. 

I guess this will need to change. Toaster needs to create a separate build directory for each project.

I don't think that the user initializing the build dir before starting toaster needs to change. Instead we will end up with something like:
toaster/build -- this was created by sourcing poky/oe-init-build-env and is where you would do command line builds that toaster is listening to.
toaster/build-Project1 - when you make a project, this build dir is initialized and a bitbake memres server is started and attached to it.
toaster/build-ProjectN - more of the same.


The fix for bug 8422 means that we will leverage sstate and downloads across all the projects so that rebuild times will be low.

We decided to do builds by simply running bitbake instead of running 2 resident processes: bitbake server and bitbake observer. This should make implementation of this feature much simpler and reliable.

Running bitbake with toasterui requires toasterui to run in build mode. Currently it can only run in observer mode.
Here is a fix for this: https://lists.yoctoproject.org/pipermail/toaster/2016-February/003952.html

Please, review.

It turned out that we still need to run bitbake server to support builds for older releaases, so I had to reimplement the implementation.

Here is first draft:
https://lists.yoctoproject.org/pipermail/toaster/2016-March/004068.html

Please, review.

v2 has been sent for review: https://lists.yoctoproject.org/pipermail/toaster/2016-March/004093.html

sent v3: https://lists.yoctoproject.org/pipermail/toaster/2016-March/004132.html

The fix has been merged to bitbake master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a43a16b9fd471d719761354eaab81409d4b07470

Verified on master.