As part of BpyBuild 5.2, one feature being worked on is improvements to build names to allow them to be a bit more "dynamic". For example, being able to specify the OS, Blender version, extension vs legacy, etc. There's some work done already from last year, but I want to lay out the overall plan that I have in mind.

• Templating: obviously we need to be able to template. At a basic level, one could do something like this:

  build_name: "MCprep_addon_{version}"

  But sometimes, we may want to have multiple options, such as x86 vs arm, or extension vs legacy. We could then extend this further, like so:

  build_name: "MCprep_addon_{version}_{extension|legacy}"

  Or lets say we don't care if a variable isn't defined, then we could do something like this:

  build_name: "MCprep_addon_{version}_{?legacy}"

  Some ideas for directives:
  • foo|bar - if foo doesn't exist, use bar
  • ?foo - if foo doesn't exist, just ignore and remove surrounding characters
  • *?foo - same as before, but don't remove surrounding characters

The string would be parsed ahead of time and validated for syntax and if a variable would exist (where needed). Perhaps in theory we could also allow extending the templating language with actions, but that's more of a "nice to have, but not required"

• Basic, built-in variables, with the ability to extend with actions: Like everything in BpyBuild, variables for templating should be extensible with actions. However, we'd want to be able to validate variable names ahead of time, so there will be 2 parts to adding new variables:

  • Create an action with the define_output_var hook
  • Add the variable to the defines section:

    dev: 
      script: "dev.py"
      ignore_filters: 
        - "*.blend"
      defines:
        - foo

  As for built-in variables, although we currently have a few in the milestone branch, I have plans to refactor it down to the following:

  • extension and legacy
  • version (based on either blender_manifest.toml or __init__.py)

  OS and CPU specific variables were originally planned, but I don't think those are really suitible to implement as a general thing (if an addon needs those things, they could just create actions based around the addon's full build process)