Buildroot versus local development


#1

Would anyone be able to provide a point of clarity in the published plugin development guide? There are instructions for two types of plugin development

  1. Buildroot
  2. Local

I’m in the process of setting up the buildroot and I have a functional LV2 plugin compiled and tested on the same system. The following line confused me

For local development of plugins using buildroot can be bothersome and confusing. You can use the cross-compiler and toolchain directly instead of going through buildroot methods.

What is the difference between the buildroot and local methods? Both directions appear to refer to building the plugin on my local system.


#2

In one case (buildroot), you are using a script that drives the whole build process (setting up the environment variables needed for the build process to use the cross-compiler/libraries instead of the build machine’s own build system) and moves everything around nicely. It is cool, but exactly tailored to do just that : fully building a plugin and prepare it for deployment.

You may just want to compile a different bit of code (for instance, @falkTX’s nooice module, that allows you to use a joystick or a guitar hero controller as an external midi controller), or to compile just one file or to do just a partial build, because you know your thing is not ready yet and that other parts of your plugin are going to cause the generation of zillions of messages that you don’t care about yet.

In that case, what you would like to have, is the ability to just use the traditional tools that you are used to on any other platform from the command line : gcc, make etc… instead of using the buildroot “black box” (well it is not really a black box, but its purpose is to be used like one).

This is what is called “Local”.

Put simply, you just need to source the right bash source file, which sets up all your environment nicely, and there you go. You are ready to do exactly what you expect : call make on your makefile that you want to test, compile just that one file for which you want to have all the warning messages, check which flags you need to use that particular lib, etc…

I hope this helps


#3

I do recommend you to use buildroot. Even better, use docker (which also uses buildroot).


#4

Why, do you believe using docker is helpfully? Just ask out of curies. If you run a linux based machine, are there any benefit in using a docker image?


#5

Standardization of the development environment. Docker ensures consistency between the machines.


#6

I’m going to set up the buildroot via docker on my macOS laptop. Yesterday I set it up on the host OS on my Linux desktop (which is a bit old) and the process took over three hours due to compiling the whole toolchain from source. My guess is docker provides speed.


#7

Sorry, I didn’t understand what you mean. If, I, develop a plugin, how, would docker be involved? As I see it, the docker image is used to deploy the plug to the MOD, isn’t it? But, that job could easily be done by the build-root. So, docker images may be of some interest for windows/MAC users, but, to be honest, were is the benefit for linux users? May I get it wrong, please en-light me.


#8

It’s not involved. You don’t need docker.

What I meant is that you know the environment where you are installing buildroot and its dependencies. It has a standard (in this case an Ubuntu 16.04).

It might not seem like a big advantage because the buildroot is the only tool you need to create plugins for the MOD. However, if you think it as something bigger, let’s say the “mod plugins development environment” where you would have more tools and those tools depends on your system libraries, the docker becomes really useful. Also, in this last case, it would be easier to setup the environment using docker because the instructions are the same, while that by doing it system-side new steps would be required.


#10

Confirmed docker provides speed. All the arm-mod-linux-gnueabihf-* stuff is compiled.