As a temporary work-around I disabled the error checking in
PropertyStackManager constructor. I assume the matcher is a little bit
too simple, but that is just a guess.
Should I create an issue for that or is my example / analysis wrong?
Regards, Jochen
Am Donnerstag, dem 10.07.2025 um 14:15 +0200 schrieb Jochen Becher via
Qbs:
>
> One more note: in the minimal example I can replace the SubProject
> with
> a references property and it works.
>
> Unfortunately, this is not a good work-around for me as I had to
> change
> hundreds of test frames in our code...
>
> Regards, Jochen
>
>
> Am Donnerstag, dem 10.07.2025 um 14:11 +0200 schrieb Jochen Becher
> via
> Qbs:
> >
> > I was able to create a small (not necessary minimal) example.
> > Please
> > see the attached zip file.
> >
> > It is much more complex than my original minimal code. The main
> > aspect
> > seems to me a change in qbs 3.0.0:
> >
> > SubProject { filePath: "MyApp.qbs" }
> >
> > seems to set parent differently than in the past. If I insert the
> > content of MyApps.qbs which is a fairly simple CppApplication
> > product
> > then it works. The module "mymodule" also seems to be important to
> > see
> > the issue.
> >
> > Regards, Jochen
> >
> >
> >
> > Am Donnerstag, dem 10.07.2025 um 13:16 +0200 schrieb Richard
> > Weickelt:
> > > Hi,
> > >
> > > > readonly property stringList onEmbedded: parent.onEmbedded
> > >
> > > > Project {
> > > > property bool mySetting: true
> > > >
> > > > Project {
> > > > property bool mySettings: parent.mySetting
> > > > ? parent.mySetting : false
> > > > }
> > > > }
> > >
> > > This looks problematic. Qbs flattens nested and merges referenced
> > > project
> > > items during the evaluation process (see
> > > https://doc.qt.io/qbs/special-property-values.html#project). The
> > > documentation does not say it, but that's what Qbs does with
> > > project
> > > items
> > > under the hood AFAIK. If you define properties with the same name
> > > shadowing
> > > each other and you use parent in addition, you may observe
> > > unwanted
> > > side
> > > effects of the project merger. Maybe you get different results in
> > > different
> > > projects because the property is evaluated at different times
> > > during
> > > the
> > > resolve proces. For instance during early project evaluation,
> > > during
> > > probe
> > > resolving or during module loading in products.
> > >
> > > I was under the impression that the special "parent" alias is
> > > only
> > > a
> > > relict
> > > from the QML parser and not guaranteed to work in Qbs. The same
> > > applies to
> > > "id". It's reserved for probes at the moment although it works in
> > > other
> > > cases too.
> > >
> > > Could you live with a different solution? This would work:
> > >
> > > Project {
> > > property bool mySetting: true
> > > Project {
> > > property bool myOtherSetting: project.mySetting
> > > ? project.mySetting : false
> > > }
> > > }
> > >
> > > Or if you explain what you want to achieve, we may find a
> > > different
> > > solution?
> > >
> > > Richard
> > >
> > > _______________________________________________
> > > Qbs mailing list
> > > Qbs@qt-project.org
> > > https://lists.qt-project.org/listinfo/qbs
> >
> > _______________________________________________
> > Qbs mailing list
> > Qbs@qt-project.org
> > https://lists.qt-project.org/listinfo/qbs
>
> _______________________________________________
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
_______________________________________________
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
