Re: [Qbs] qmath3d build issue

2020-02-19 Thread Christian Kandeler
On Wed, 19 Feb 2020 12:18:13 +
Wookey  wrote:

> I maintain a couple of debian packages that build with qbs.
> 
> Last night, whilst fixing a couple of bugs in qmath3d 
> (https://tracker.debian.org/pkg/qmath3d) I found a problem: it used to build 
> but no longer does.
> 
> Well it builds fine but the qbs install step is installing to:
> $(CURDIR)/debian/tmp/usr/local/usr/lib//

"$(CURDIR)/debian" is the install root
"/usr/local" is the install prefix (this is the default value on Unix)
"/usr/lib//" comes from somewhere else; presumably someone sets 
qbs.installDir to that.

> instead of 
> $(CURDIR)/debian/tmp/usr/lib//
> 
> when given:
>   qbs install --settings-dir debian --no-build \
>--install-root $(CURDIR)/debian/tmp \
>project.libDir:lib/$(DEB_HOST_MULTIARCH) \
>profile:deb \
>config:qbs-build
> 
> If I also configure with:
> qbs config --settings-dir debian profiles.deb.qbs.installPrefix usr/

This looks sensible and appears to be the "conceptually correct" solution.

> then it installs into
> $(CURDIR)/debian/tmp/usr/usr/lib//
> (so we got rid of the 'local', but still have two 'usr's)
> 
> To make it work I now have to do:
> qbs config --settings-dir debian profiles.deb.qbs.installPrefix ""
> 
> All this doesn't seem to fit with InstallPrefix and InstallRoot info on
> https://doc.qt.io/qbs/qml-qbsmodules-qbs.html#installation-properties
> 
> I'm not sure what's going on, and why it has changed.
> installing to
> /usr/local/usr/lib/
> seems almost always likely to be wrong.

Sure, but that's the fault of who/whatever sets the "/usr/lib" thing. The 
project itself perhaps?

> I have made it work, but it used to be that the path was correctly 
> constructed from
> 
> but that seems no longer to be true, and now I don't understand what it is 
> doing.

It worked by coincidence, because qbs.installPrefix used to be empty by 
default. Now that it isn't anymore, it becomes painfully obvious that someone 
has put a "/usr" where it doesn't belong. (Presumably the project, and 
presumably into qbs.installDir).

> I'm on qbs 1.13.1, and I guess it was 1.11 or 1.12 last time I tried any of 
> this.
> 
> Is this a deliberate change in behaviour

Yes. Giving qbs.installPrefix a sensible default makes it more obvious to new 
users what the responsibilities of the different install* properties are, and 
as a side effect uncovers mistakes like the one we are seeing here.
Of course, one can also choose to ignore all of this and continue as before by 
forcing qbs.installPrefix to an empty string.


Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


[Qbs] qmath3d build issue

2020-02-19 Thread Wookey
I maintain a couple of debian packages that build with qbs.

Last night, whilst fixing a couple of bugs in qmath3d 
(https://tracker.debian.org/pkg/qmath3d) I found a problem: it used to build 
but no longer does.

Well it builds fine but the qbs install step is installing to:
$(CURDIR)/debian/tmp/usr/local/usr/lib//
instead of 
$(CURDIR)/debian/tmp/usr/lib//

when given:
qbs install --settings-dir debian --no-build \
   --install-root $(CURDIR)/debian/tmp \
   project.libDir:lib/$(DEB_HOST_MULTIARCH) \
   profile:deb \
   config:qbs-build

If I also configure with:
qbs config --settings-dir debian profiles.deb.qbs.installPrefix usr/

then it installs into
$(CURDIR)/debian/tmp/usr/usr/lib//
(so we got rid of the 'local', but still have two 'usr's)

To make it work I now have to do:
qbs config --settings-dir debian profiles.deb.qbs.installPrefix ""

All this doesn't seem to fit with InstallPrefix and InstallRoot info on
https://doc.qt.io/qbs/qml-qbsmodules-qbs.html#installation-properties

I'm not sure what's going on, and why it has changed.
installing to
/usr/local/usr/lib/
seems almost always likely to be wrong.

I have made it work, but it used to be that the path was correctly constructed 
from

but that seems no longer to be true, and now I don't understand what it is 
doing.

I'm on qbs 1.13.1, and I guess it was 1.11 or 1.12 last time I tried any of 
this.

Is this a deliberate change in behaviour, in which case can someone
explain the new logic, or is it a bug?

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] Interfacing Qbs to Conan

2020-02-19 Thread Jochen Ulrich
>  It would be great if Qbs 1.16 could offer a complete Conan story. We have 
> roughly a month until feature freeze.

The ticket(s) I will create are not a requirement for the Conan ModuleProvider 
we implemented. So we should not have a problem with this deadline.
The things from the ticket(s) would just allow a simpler/better implementation 
of the ModuleProvider and improve its usability.


> It might be beneficial if module providers [...]

Yeah. Those three things would really be helpful.


> I do not think they should have direct access to probes/properties defined in 
> the project/product by the user because this would be an "invisible" 
> dependency. That means: A provider should not rely on 
> project.mycustomProperty.

Okay. That's true. And if the other three things would be possible, it would be 
unnecessary to have access to the probes/properties defined in the 
project/product.


> Are you aware that module providers operate on product level? You can 
> (currently) configure them in the profile and in the product.

Yeah but that's not correct for the Conan ModuleProvider and probably also for 
other ModuleProviders. What they need are properties on *project* level.
They should not be configured in a profile because they are specific to a 
project. And you don't want to repeat them for every product in the project.


> We could also add the capability to "configure" the fallback provider via the 
> Depends itemĀ [...]

I also thought about this. However, I would call the property simply 
"providers" instead of "fallbackProviders":

Depends {
name: "mylib"
providers: [
"conan",
"pkgConfig"
]
}


>https://codereview.qt-project.org/c/qbs/qbs/+/288927 achieves automatic 
> probe re-execution by assigning the modification time stamp of the conanfile 
> to a property of the probe.

Yeah. Something like this. Except for ModuleProviders.


>An --force-module-generator-execution command line flag might be worth to 
> add to qbs resolve.

I would call it --force-module-provider-execution to make it clear that its 
related to the ModuleProviders.


So to summarize: we have the following new requirements regarding 
ModuleProviders:

1. ModuleProviders should be able to define their own probes.
2. ModuleProviders should be able to define a logic to "invalidate" their 
generated modules (force regeneration of the modules).
3. ModuleProviders should be able to access the project and product they live 
in.
4. Projects should be able to configure ModuleProviders like it is possible in 
products.
5. Depends items should be able to define which ModuleProviders to use. Doing 
this invokes the ModuleProvider like a fallback ModuleProvider (meaning it gets 
the complete "name" of the Depends item).
6. qbs resolve should provide a command line flag 
--force-module-provider-execution to force regeneration of modules by 
ModuleProviders.

Should I create one or multiple tickets for these requirements?
To me it sounds like 1, 3 and 4 might be related while the others are rather 
independent.

Best
Jochen



___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs