`button convert build.sh` is not recursive

[mihails-strasuns]

If used on project which uses button-lua for actual description, following shell script gets generated:

#!/bin/bash
# This file was automatically generated by Button. Do not modify it.
set -xe -o pipefail
button-lua BUILD.lua -o .BUILD.lua.json
button build --color=always -f .BUILD.lua.json

This is not very practical considering the purpose of build.sh conversion. Desired output would be to flatten all recursive calls and output single linear command sequence.

[jasonwhite]

Yeah, this would be nice to fix.

In order to flatten, we would need to execute button-lua BUILD.lua -o .BUILD.lua.json while producing the bash script because the complete build graph is still unknown. Only then can the recursive call be flattened. For button-lua, this is not much of a problem because the Lua scripts are not allowed to modify the outside world, only read from it. However, for other (potential) build description generators, it could be an issue if they do modify the outside world.

If the recursive invocation of button is only one level deep, then one can work around this issue by doing this instead:

$ button-lua BUILD.lua -o .BUILD.lua.json
$ button convert -f .BUILD.lua.json build.sh

[mihails-strasuns]

How about actually executing clean build while memorizing all used commands? The only issue that comes to my mind is that output from recursive builds would need to be placed in temporary file somewhere for future aggregation.

[jasonwhite]

That's not a bad idea actually. The convert sub-command could be removed and this functionality could be integrated with the build sub-command instead.

I'd like to give the option to output complete information about the build such as: the build tasks, how long they took to run, when they ran, success and failure status, etc. This information could then be post-processed to create the bash script (or other things, like Gantt charts). This could be implemented generically with some sort of event logger. Since all builds are incremental (unless a clean is done first), the only problem is that this information could be a subset of the whole thing, but that could also be considered a feature.

In short, implementing an event logger should help solve this problem and quite a few others. (Imagine having a web interface with an interactive build graph that gets updated in real-time.)

[mihails-strasuns]

Sounds cool!

To make it work conveniently there also needs to be another independent feature - way to pass command-line flags to recursive button calls (i.e. akin to MAKEFLAGS). Does button currently have any notion of variables in json definition?

[mihails-strasuns]

By the way, could you please ping me via e-mail (public at dicebot.lv)? I'd like to ask some generic questions that don't fit into github issue format.

[jasonwhite]

To make it work conveniently there also needs to be another independent feature - way to pass command-line flags to recursive button calls (i.e. akin to MAKEFLAGS). Does button currently have any notion of variables in json definition?

Command line arguments can be passed to button-lua to alter how it generates the build description. You could pass in a .json file there, but there is no built-in JSON parser so you'd have to get a pure-Lua JSON parser somewhere.

By the way, could you please ping me via e-mail

Done.