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

Introduce a "neutral" item for structuring purposes

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Reported
    • Priority: Not Evaluated
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Technical Risk:
      Normal

      Description

      Currently, people are forced to write their project files a bit redundantly once conditions come into play:

      Product {
          // ...
          Depends {
              name: "special_module"
              condition: qbs.targetOS.contains("windows")
          }
          Properties {
              condition: qbs.targetOS.contains("windows")
              special_module.someProperty: "x"
          }
          Group {
              condition: qbs.targetOS.contains("windows")
              files: ["windows_helper.cpp"]
          }
      }
      

      Instead, we would like to write:

      Product {
          // ...
          Item { // Real name tbd
              condition: qbs.targetOS.contains("windows")
              Depends {  name: "special_module" }
              special_module.someProperty: "x"
              Group {
                  files: ["windows_helper.cpp"]
              }
          }
      }
      

      This new item type would behave as follows:

      • Its only property is "condition".
      • It allows the same child items as its parent item (including itself, i.e. it is nestable).
      • The conditions of all child items are implicitly AND'ed with the condition of the item.

      Note that this would also solve the problem of sharing source files between products: While this is already possible by putting a Groups into a dedicated qbs file, we can neither add dependencies nor set properties for other source files in there, so the qbs file cannot always be made self-contained.

      The main challenge here is probably dealing with property assignments. For instance:

      Item {
          condition: x
          cpp.defines: "X"
      }
      Item {
          condition: y
          cpp.defines: "Y"
      }
      

      The conditions x and y are not necessarily disjunct, so if both are true, cpp.defines needs to get merged, similarly to how it's done with property assignments from different modules.
      Also, if both conditions are false, cpp.defines must not be affected at all. This might sound obvious, but is not how the Properties item currently behaves and probably requires quite a bit of tinkering with low-level code.

        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:
              kandeler Christian Kandeler
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:

                  Gerrit Reviews

                  There are no open Gerrit changes