[Qbs] Heads up: Deprecations in master branch

[Christian Kandeler]

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