search

bloombloombloom / Bloom

A debug interface for AVR-based embedded systems development on GNU/Linux.
https://bloom.oscillate.io/
Other
64 stars 3 forks source link

Allow building without including Insight #41

Closed septatrix closed 2 years ago

septatrix commented 2 years ago

When only using Bloom as a GDB server this is not needed. Hiding insight behind a feature flag would shrink the binary and reduce dependencies making it easier to port it to other architectures and distributions.

navnavnav commented 2 years ago

Hmm, I'm not so sure about this.

I don't think the gain justifies the additional effort required in development and maintenance.

Even if I were to ignore the development work this would require, the additional maintenance work required for this would be:

Those are just the points from the top of my mind. There are probably others.

Furthermore, I feel like this would be taking Bloom in a direction that I never intended. Bloom was designed to run on development machines - machines that embedded developers would use for development - machines that can handle a 3.2 MB binary. It wasn't designed to run on resource-constrained machines.

I know that Insight causes Bloom to use around 30-40 MB of RAM, instead of the 4-6 MB when Insight is disabled. The way I see it is: If you can run a modern bulky web browser (like Google Chrome's 190 MB binary), or an IDE like CLion on your machine, you should have no problem running Bloom. If your machine can't handle running modern IDEs or web browsers, then Bloom wasn't intended to run on it.

I may change my mind on this at a later date, but for now, I don't want to worry about binary size as I feel a 3.2 MB binary should not be a problem for any of the intended users. Apologies if this is going to be a problem for you.

What architectures/distributions are you looking to run Bloom on? If these are not significantly resource-constrained and used as development machines, by embedded developers, I will consider supporting them (but only once there is clear evidence of demand).

septatrix commented 2 years ago

Even if I were to ignore the development work this would require, the additional maintenance work required for this would be:

  • Building and maintaining separate packages for every release
  • Performing the same testing on multiple binaries
  • Managing multiple binaries with a different set of shared object dependencies - this is a form of hell that I'm not willing to suffer any more than once.
  • Ensuring that all new code is decoupled from the Insight component - although I already aim to keep each component within Bloom loosely coupled, there are instances where coupling can save me a lot of time, at least as a temporary solution, even if it's not the best approach from a software-design perspective.

Those are just the points from the top of my mind. There are probably others.

I have not yet taken a look at the code so I am not sure how strongly some of the stuff is currently linked but given that it can be disabled there do not seem to be codepaths which require it leaving only some potential compiler/linker troubles. That being said I do not expect you to be distributing multiple package versions. Just like many stuff in other projects can be disabled (apache, curl, linux kernel) it is so only for some specific use cases and the published packages always contain all the features.

Furthermore, I feel like this would be taking Bloom in a direction that I never intended. Bloom was designed to run on development machines - machines that embedded developers would use for development - machines that can handle a 3.2 MB binary. It wasn't designed to run on resource-constrained machines.

[...]

What architectures/distributions are you looking to run Bloom on? If these are not significantly resource-constrained and used as development machines, by embedded developers, I will consider supporting them (but only once there is clear evidence of demand).

We intent to run Bloom on some Raspberry Pis (i.e. arm64) such that students are able to access our development boards remotely to implement their assignments as well as on the computers inside the lab. As the RPis are headless devices they do not have any of the GUI libraries installed. Checking on a headless x86_64 machine of mine showed that apt install ./Bloom-0.9.1-Linux.deb would pull in about 400MB of dependencies...

navnavnav commented 2 years ago

I have not yet taken a look at the code so I am not sure how strongly some of the stuff is currently linked but given that it can be disabled there do not seem to be codepaths which require it leaving only some potential compiler/linker troubles.

It's not tightly coupled, but that doesn't mean it won't be a lot of work and pain to completely strip out the Insight component when a feature flag has been set. And that's not just in the initial development work, but also in the maintenance. I'll still have to test multiple binaries, constrain any new changes in other components from touching the Insight component, handle support requests for different build configurations, and manage optional shared object dependencies which will lead to pain further down the line - pain that I will have to deal with. And the idea of polluting my codebase with #ifdefs doesn't sit well with me either.

We intent to run Bloom on some Raspberry Pis (i.e. arm64) such that students are able to access our development boards remotely to implement their assignments as well as on the computers inside the lab. As the RPis are headless devices they do not have any of the GUI libraries installed.

I see. I'm afraid Bloom was not designed to accommodate this use case, and more importantly, it's not something I'd be able to accommodate with respect to the development and maintenance required. I'm sorry @septatrix, but I'm going to have to reject this.

What I fear most is Bloom becoming a chore. When development and maintenance becomes too painful, Bloom will become a chore. And at that point, it won't be long before I begin to lose interest. I hope you understand.

As an alternative, you could always fork the repo and maintain your own headless version of Bloom.