Hi,
I'd like to point out two upcoming behavior changes.
==================================================
1. Path properties in Export items
Initially, the "product" variable, when used in an Export item, referred
to the product the Export item was in, i.e. the exporting product. This
was dubious, because Export items are supposed to behave like modules,
where the product variable refers to the product that depends on the
module, i.e. the importing product. Therefore, we introduced the
"exportingProduct" variable and changed the behavior in qbs 1.22.
However, we forgot about path properties. Consider this example, which
you might encounter in a library product:
Export {
Depends { name: "cpp" }
cpp.includePaths: "."
}
Even after the aforementioned change, such a path was still resolved
relative to the exporting product, which was now inconsistent. We have
therefore deprecated this construct and will change the behavior such
that the base directory will be the importing product's.
Instead, you can simply refer to the exporting product's source
directory explicitly via "exportingProduct.sourceDirectory".
==================================================
2. The "implicit else" for list properties used in Properties items
A long-standing major annoyance with the Properties item was that its
conditions could not overlap to append different values to lists:
Properties {
condition: qbs.targetOS.contains("unix")
cpp.defines: "OS_UNIX"
}
Properties {
condition: qbs.targetOS.contains("linux")
cpp.defines: "OS_LINUX"
}
This now works as intended and produces ["OS_UNIX", "OS_LINUX"] if the
target OS is Linux.
However, there is a glitch: If the same property is also set outside a
Properties item, such a value is considered only if none of the
Properties items match. This is fine for scalar properties, for which
there can only be one value, but makes little sense for list properties,
where you often have common values that you'd like to append to
conditionally. This was traditionally done via the "outer.concat" idiom,
which is conceptually incompatible with overlapping conditions, as the
same values will potentially get added to the list several times.
Therefore, for list properties, bindings outside Properties items will
no longer act as fallbacks, but will be considered unconditionally. In
the rare cases where the current behavior is wanted, you can use a
Properties item with an explicitly "undefined" condition:
Properties {
condition: undefined
cpp.defines: "OS_NONE"
}
==================================================
The timeline for both of these behavior changes is as follows:
2.5: Deprecation message (opt-in)
2.6: Deprecation message (opt-out)
2.7: Behavior change
I will write another reminder when we actually implement the behavior
switch.
Christian
_______________________________________________
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
