[Qbs] Heads up: Deprecations in master branch

[Björn Schäpers]

A big +1 from me.

I already ported my products, took me 3 hours and has to go through review, 
wasting more time of my colleagues.

Kind regards,
Björn.

Am 05.08.2024 um 19:12 schrieb Jochen Becher via Qbs:
> 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
> _______________________________________________
> Qbs mailing list
> Qbs at qt-project.org
> https://lists.qt-project.org/listinfo/qbs