libbelaextra - incomplete

[TheTechnobear]

libbelaextra only contains some of libraries

(I need everything for cross-compilation)

is there any reason not to change Makefile

FROM:

LIB_EXTRA_OBJS = $(EXTRA_CORE_OBJS) build/core/GPIOcontrol.o libraries/Scope/build/Scope.o libraries/UdpClient/build/UdpClient.o libraries/UdpServer/build/UdpServer.o libraries/Midi/build/Midi.o libraries/Gui/build/Gui.o

TO:

LIB_EXTRA_OBJS = $(EXTRA_CORE_OBJS) build/core/GPIOcontrol.o libraries//build/.o

note: its a bit unclear to me why GPIOcontrol is not in libbela.a and so is required in libbelaextra ?!

---

another option might be...

rather than to have bela + belaextra

to have:
libbela & libbelacomplete

where complete = all build//.o + all libraries//build/.o
so you only need to link one library.

[giuliomoro]

the rationale for shared /static libraries is loosely as follows:

• libbela should contain the barebones, whatever is needed to start a minimal Bela program: start the audio environment, codecs and PRU.
• libbelaextra contains a handful of common extra tools which until recently used to be in core/, i.e.: Scope, Midi and their dependencies and Gui.

Supercollider scsynth links to -lbela only, as it uses its own Midi interface and does not give access to the Bela Scope.
Csound links to both lbela and lbelaextra because it uses the Scope (and possibly Midi from Bela?).
In several of my projects I use both (which - incidentally - is the reason why they were created in the first place :) ).

The libraries (as in: the /root/Bela/libraries folder) are a complex beast. In principle, there could be some user-provided code in there, and we decided to detect libraries at link time for each project so that broken code in one library, or symbol conflicts, wouldn't prevent all programs on the board from building. This limitation similarly applies to a potential lbelacomplete. Currently there is one lib: target in the Makefile that creates both static and shared files for lbela and lbelaextra, and this target is a dependency for running Supercollider and Csound projects. For your use case I guess we could add a lbelalibraries as a separate target that is not a dependency for the Sc and Cs projects. This way if it breaks it is the advanced user's problem, and not everyone's. What do you think?

[giuliomoro]

note: its a bit unclear to me why GPIOcontrol is not in libbela.a and so is required in libbelaextra ?!

It is in both actually. I think I needed it for a project where I was only using libbelaextra and not libbela. There is no good reason why it should stay like this though that I can think of, though.

[TheTechnobear]

now sure what you exactly mean by 'user-provided' code...
I separate code into 'core' code which will always be known to be working ... and I have said anything i the bela repo should be this.

then 'user libraries' which are additional 'optional' libraries which are not 'supported' by the Bela team and help in a different repo - say a 'community library'?
the scope of this, I would say is stuff thats interesting, but not considered a fundamental part of the Bela experience e.g. say an OLED Driver?

anyway....
as you say, Im ok adding a another target/library. that is a complete library
basically includes everything in core and libraries....

I'll send you a PR...

[giuliomoro]

now sure what you exactly mean by 'user-provided' code...

A user could create their own library and store it in Bela/libraries to be able to re-use it across projects. Currently we do not provide facilities to do it through the IDE, though in the future we should.