[BuildStream] BuildStream Gathering 2018 topic: Debugging multiple elements
- From: Chandan Singh <chandan chandansingh net>
- To: buildstream-list gnome org
- Subject: [BuildStream] BuildStream Gathering 2018 topic: Debugging multiple elements
- Date: Mon, 15 Oct 2018 19:08:04 -0400
Hi,
I had proposed the
"Debugging multiple elements - involving host tools, Docker etc" topic for
the upcoming BuildStream Gathering, here are some details and motivations for
this topic.
Use Case
========
The use case that I'd like us to consider is where one is trying to debug
multiple elements at once - say one (or more) libraries and one (or more)
apps
Currently, the way to tackle this situation is to start by opening workspaces
for all the elements involved. Then, the edit-test cycle basically becomes:
- Make changes
- Run `bst build`
This is not great because of the following reasons:
- it can be rather time-consuming, as making even a small change in the library
would fully rebuild all its dependents. In essence, we do not have
incremental builds across elements.
- BuildStream's build shell does not support staging multiple elements as
sources so that would not work in this case either
- Using debuggers etc is also not straightforward. if they are not in the
BuildStream project at all, it becomes especially hard because one cannot
get around this by adding additional build dependencies.
Can we make it better?
======================
I would like us to brainstorm on the best approaches to handle the above use
case. I am listing below some of the ideas that were mentioned in the past
just as conversation starters:
- Using a similar strategy as bst-docker-import [0], one could "escape" to
Docker after checking out the sources for the targets but Docker may not
always be an option.
- Can somehow allow building using host tools for debugging purposes. Similar
to DummySandbox added recently, we could have a No-Op Sandbox that would
simply launch host tools instead of launching a proper sandbox. Obviously,
this mode will be provided with a warning like
"caution: use at your own risk" and we would not trust any artifacts
generated by such builds. But, it may be quite useful to involve debuggers
etc.
- Can also allow launching build shell for multiple elements so that user
has the sources for all of them.
These are just some ideas I can think of right now, we should discuss this in
more detail in person.
Looking forward to seeing you all soon.
[0]: https://docs.buildstream.build/additional_docker.html#generate-docker-images
Cheers,
Chandan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]