Uploaded image for project: 'Qbs ("Cubes")'
  1. Qbs ("Cubes")
  2. QBS-1528

a more elegant way to aggregate multiplexed products

    XMLWordPrintable

    Details

    • Type: Suggestion
    • Status: Reported
    • Priority: Not Evaluated
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      currently, aggregation is implemented via a "magic" pass that is added on top of the variant passes of a multiplexed product. when one wants to do selective aggregation (e.g., to join architecture variants into fat binaries while leaving build variants side by side), one has to explicitly loop in the aggregation pass.

      to address this, building on top of the finer multiplexing granularity stipulated by QBS-1527, the idea would be to let expressions aggregate some properties (i.e., access their variant values as a single array) while still being multiplexed over others (i.e., have the expression be evaluated in multiple passes).

      i can think of two approaches to specify such selective aggregation:

      Approach 1

      specify the aggregated axes as a property of the rule (and possibly other items where aggregation would make sense), so at the expression level there would be no syntactical distinction between muxing over a property and accessing its aggregate.

      Example

      // FIXME: this is obviously pseudo-code
      Rule {
          name: "lipo"
          aggregate: "cpp.arch"  // some kind of symbolic reference
          prepare: {
              path = destDir + cpp.buildVariant  // this is muxed over
              command = "lipo -o " + path + " " + inputs.join(" ")  // this is aggregated along the arch axis
          }
      }
      

      Approach 2

      have a separate syntax to allow expressions to explicitly accesses the aggregate multiplexed property, for example propname.MUX, or a dedicated operator.

      Examples

      MuxProps {
          arch: [ "x86", "arm" ]
          type: [ "debug", "release" ]
      }
      knolf: "foobar"
      
      // aggregation of one-axis muxing
      // => "foobar x86 arm baz"
      agg_1d: knolf + " " + arch.MUX.join(" ") + " baz"
      
      // partial aggregation of two-axis muxing
      // => "foobar debug x86 arm baz"
      // => "foobar release x86 arm baz"
      agg2_2d: knolf + " " + type + " " + arch.MUX.join(" ") + " baz"
      
      // two-axis muxing
      // => "foobar x86 debug baz"
      // => "foobar x86 release baz"
      // => "foobar arm debug baz"
      // => "foobar arm release baz"
      deriv_2d: knolf + " " + arch + " " + type + " baz"
      
      // aggregation of transitive two-axis muxing
      // => "agg foobar x86 debug baz foobar x86 release baz foobar arm debug baz foobar arm release baz"
      agg_deriv_2d: "agg " + deriv_2d.MUX.join(" ")
      
      // partial aggregation of transitive two-axis muxing
      // - this shows that muxing over an axis takes it out of the aggregate
      // => "agg x86 foobar x86 debug baz foobar x86 release baz"
      // => "agg arm foobar arm debug baz foobar arm release baz"
      agg2_deriv_2d: "agg " + arch + " " + deriv_2d.MUX.join(" ")
      

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              Assignee:
              kandeler Christian Kandeler
              Reporter:
              buddenha Oswald Buddenhagen
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:

                  Gerrit Reviews

                  There are no open Gerrit changes