Developing applications and libraries at the same time should be easier

[See original issue on GitLab](https://gitlab.com/BuildStream/buildstream/-/issues/432)
In GitLab by [[Gitlab user @TheRealMichaelCatanzaro]](https://gitlab.com/TheRealMichaelCatanzaro) on Jun 20, 2018, 15:40

## Background

Switching from a library workspace to an application workspace after making changes to the library is cumbersome. For example, say I want to make some changes in library L and test them in application A. Opening a build shell for library L does not really work, since a full `bst build L.bst` is required to get an updated version of library L into application A's shell. So my current workflow is to `bst build L.bst` outside any shell, then enter a A.bst shell to test my changes. Let's say I'm debugging an issue by adding printfs to the library. That means I have to build, enter the shell, find any problems with my change (it's not enough, I need another printf!), exit the shell, build again, reenter the shell... and entering and exiting shells takes a nontrivial amount of time. It's simply harder to do serious library development with BuildStream than it is without.

I don't know what we could do about this. I guess one option would be to allow building multiple elements in a single shell, so e.g. I could hack on WebKit (library L) without leaving my Epiphany (application A) shell.

## Task description

Not sure

## Acceptance Criteria

Not sure.

The issue names no files, tests, or concrete entry point beyond `bst build` and application/library shells. Start by reproducing the described library-and-application workflow and tracing the relevant shell and build commands; done would require an agreed workflow and acceptance criteria, which the issue currently leaves unspecified.

Written by the indexing model from the issue text.