Does anything speak against replacing that internal BMK-Lua-script thing with Lua?
I ask as it would help to write some helper functions to retrieve the "to use" path for extra files (.settings, .ico, ...). All of them share the same idea ("if outputfile[.ending] not found, use inputfile[.ending] - or undecorated or ..."). To have all these lines do the very same sounds ... hmpf.
Also some comments in make.bmk seem to say that they would like to call a bmk-defined-function in a bmk-defined-function - which is for now not possible.
It shouldn't be that hard to expose some functionality of BMK (or type instances) to Lua (maybe via brl.MaxLua - or my Dig/base.util.luaengine.bmx replacement). Also calling Lua functions from within BMK isn't that troublesome.
This also means we could more clearly define functions + params instead of relying on arg1, arg2 etc getting handled within BMK.
Worth the hassle or better add "bmk-lua-script"-support for calling in-script-defined functions in functions declared there too?
Does anything speak against replacing that internal BMK-Lua-script thing with Lua?
I ask as it would help to write some helper functions to retrieve the "to use" path for extra files (.settings, .ico, ...). All of them share the same idea ("if outputfile[.ending] not found, use inputfile[.ending] - or undecorated or ..."). To have all these lines do the very same sounds ... hmpf.
Also some comments in make.bmk seem to say that they would like to call a bmk-defined-function in a bmk-defined-function - which is for now not possible.
It shouldn't be that hard to expose some functionality of BMK (or type instances) to Lua (maybe via brl.MaxLua - or my Dig/base.util.luaengine.bmx replacement). Also calling Lua functions from within BMK isn't that troublesome.
This also means we could more clearly define functions + params instead of relying on
arg1,arg2etc getting handled within BMK.Worth the hassle or better add "bmk-lua-script"-support for calling in-script-defined functions in functions declared there too?