parse `settings.json` from C++

[giuliomoro]

Add command-line option --jsopts to pass a path to a .json file containing command-line options. E.g.:

/root/Bela/projects/projectname/projectname --jsopts /root/Bela/projects/projectname/settings.json

Multiple --jsopts should be allowed (to override previous declarations). Intermixing --jsopts and other command-line options should allow to override settings so that only the latest setting specified (be it in a json or at the command line) is applied. This should be built into Bela_getopt_long(), so that there is no change needed to legacy custom main.cpp to support the new feature. core/JSON.cpp should already have all that is needed to parse the JSON.

Caveats: make runide should call

/root/Bela/projects/projectname/projectname --jsopts /root/Bela/projects/projectname/settings.json

Therefore the IDE needs to make sure it has actually finished writing settings.json before it calls make runide.

[adanlbenito]

There is a json.parse in the core code (json.h). Example of usage in scope.cpp

[giuliomoro]

file1.json has CL="-X 2 -C 4" file2.json has CL="-G 0 -D 2" then they should be expanded recursively in place so that

./belaproject -C 2 --jsopts file1.json -C 8 --jsopts file.json

should be equivalent to

./belaproject -C 2 -X 2 -C 4 -C 8 -G 0 -D 2

[giuliomoro]

An additional issue here is that there are now many layers of overriding and this needs to be thought through holistically to reach a rational solution, because things are already complicated enough. The options that are used to configure the program are stored in the BelaInitSettings object in main() (see here). This is populated as follows (in order, with each step overwriting the existing content):

• the call to Bela_defaultSettings() (see):
  • the function body sets Bela's internal defaults and then calls Bela_userSettings()
  • Bela_userSettings() is an optional function that the user may define in the user code. If defined, it is called at the end of Bela_defaultSettings(). For example usage, see here
• a subset of the BelaInitSettings can then be overridden by "command line" options in the Bela_getopt_long loop (see). Such "command line" is formed by splicing together, in order:
  • the contents of the CL= entry in the userBelaConfig file (typically /root/.bela/belaconfig, see here
  • the actual command line options passed to the process. This typically happens in three possible ways (which are all the same as a far as the running process is concerned, but worth listing here for completeness):
  • directly running ./myproject -a -b -c
  • by passing the CL=" " variable to make run, e.g.: make -C /root/Bela run PROJECT=myproject CL="-a -b -c", which in turn calls the above
  • by setting the options in the IDE, which populates the project's settings.json and in turn calls make above with the CL=" " options set from parsing settings.json.

Note: currently the IDE's command line options will set all (or at least most, because some have been deprecated and some others may have been forgotten) command-line options available, which means that the command line options stored in CL= in the userBelaConfig file will most likely be entirely overridden by the contents of settings.json when running from the IDE. This makes sense because as far as the process knows, this is "hard-coded" (on disk) options from userBelaConfig vs "runtime" options passed on the "command-line", so it makes sense that the latter "wins" even though they are actually coming from another file (settings.json)