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

Introduce a "neutral" item for structuring purposes

    XMLWordPrintable

Details

    • Task
    • Resolution: Unresolved
    • Not Evaluated
    • None
    • None
    • None

    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

          For Gerrit Dashboard: QBS-1361
          # Subject Branch Project Status CR V

          Activity

            People

              kandeler Christian Kandeler
              kandeler Christian Kandeler
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:

                Gerrit Reviews

                  There is 1 open Gerrit change