[Qbs] Heads up: Deprecations in master branch

[Jochen Becher]

Qbs is now over 10 years old. We are using it with thousands of qbs
files. Still having breaking changes like this is a nightmare: We have
to go through formal release procedures for more than hundred
components, update binary deployments of these, integrate changes into
hundreds of streams, updating thousand files. Not funny and very
expansive.

IMHO you should think about a solution that is backwards compatible,
e.g. keeping the default behaviour and adding something new for future
code.

And btw why should an include path definition be relative to some
importing product and not the exporting product? Your example is a
perfect example why the old behaviour is readable and make sense (at
least from my point of view as a heavy user of qbs and not a developer
of the tool)

Regards, Jochen


Am Freitag, dem 02.08.2024 um 11:04 +0200 schrieb Christian Kandeler
via Qbs:
> 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 at qt-project.org
> https://lists.qt-project.org/listinfo/qbs