Re: [Qbs] Interfacing Qbs to Conan

2020-02-06 Thread Jochen Ulrich
Hi Richard!

> I hope this gives you some ideas how to move forward

Thanks Richard! We really appreciate your help!


> There might be different solutions to this, but what I think would be simple 
> and straight forward

Basically, we are doing it the way you described.
However, we decided not to make a conan module which the generated modules 
depend on because we expect that this would lead to multiple invokations of 
`conan install` (one for each generated module) which we want to avoid.
So we decided to have a project-level probe instead which detects the conan 
executable and the conanfile and runs `conan install`.
This way, one can also easily define the path to the conanfile inside the Qbs 
files.


> I would be more than happy to discuss any issues appearing on the way.

Yeah. While working on the Conan ModuleProvider, we encountered a few 
obstactles. Luckily, it seems we are able to work around them.
I list these obstacles here along with the workarounds we are currently 
implementing so we can discuss them.
I would then create a feature request ticket to extend the ModuleProvider 
accordingly.

So the following things might be helpful when writing a ModuleProvider:

1.) Access to (project-level) probes
It is quite likely that a ModuleProvider needs some external tools or files and 
those should be detected using probes.
In our case, we need to detect the conan executable and the conanfile(s).
Our workaround is to let the project-level probe execute `conan install` so the 
ModuleProvider does not need to know the location of the conan executable and 
the conanfile(s). This then produces a conanbuildinfo.json which the probe 
places in a defined location inside the build directory so that the 
ModuleProvider is able to find it.

2.) Access to the project the ModuleProvider is running in
A ModuleProvider might need or save some files in the buildDirectory. So access 
to the project.buildDirectory and project.sourceDirectory would be helpful.
In our case, we need to locate the conanbuildinfo.json in the buildDirectory. 
Enhancement 1.) might also solve this. However, in our project, we might end up 
with several conanbuildinfo.json files (hierarchy of projects) and therefore, 
access to project.name to differentiate the files might be helpful.
Our workaround to get the buildDirectory is to assume that the outputBaseDir of 
the ModuleProvider is inside the build directory. So we simply do something 
like `var buildDirectory = FileInfo.cleanPath( outputBaseDir + '/../..' )`.
For the multiple conanbuildinfo.json files issue, we simply take all of them 
inside a defined directory.

3.) Access to the full name of the Depends items for which the ModuleProvider 
was called
This works for the fallback ModuleProvider AFAIK. However, at the moment there 
can be only one fallback ModuleProvider AFAIK. So it would not be easily 
possible for a project to use both pkgConfig and Conan, right?
Allowing access to the full name of the Depends item in a regular 
ModuelProvider when evaluating the relativeSearchPaths property would allow 
writing something like `Depends { name: "conan.somePackage" }` which would 
invoke the conan ModuleProvider which would then generate the Module for 
"somePackage".
Our workaround is to generate Modules for all dependencies from the conanfile, 
no matter if they are used as Depends items in Qbs or not.
So this is not a real issue in our case but it limits ModuleProviders which do 
not have something like the conanfile but only rely on the name of the 
dependency.

4.) Mechanism to force execution of the ModuleProvider
Since ModuleProvider generate modules on a dynamic basis, it is not unlikely 
that the environment changes and the ModuleProvider needs to re-run. At the 
moment, this can be forced with the --force-probe-execution command line 
parameter. However, it would be nice if Qbs could detects this automatically. 
I'm not sure how this could be realized. Maybe a property on the ModuleProvider 
that, when it evaluates to `true`, forces re-execution of the ModuleProvider?
In our case, we would like to re-run the ModuleProvider when the conanfile (or 
conanbuildinfo.json) has changed.
Our workaround is that we have to call qbs with --force-probe-execution 
manually when the conanfile has changed.


So would those enhancements make sense?


Best regards
Jochen

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


Re: [Qbs] Construction project.buildDirectory

2020-02-06 Thread Карелин Павел

Richard, Christian, thanks for the information.
How will I have the opportunity to upgrade to the new version of QtC - I 
will  look at this fix


--
BR, Pavel Karelin


06.02.2020 18:44, Christian Kandeler пишет:

On Thu, 6 Feb 2020 16:08:42 +0100
Richard Weickelt  wrote:


sorry for breaking this. The issue has been fixed by
https://codereview.qt-project.org/c/qbs/qbs/+/289271 and the fix will be in
Qt Creator 4.11.1 which is about to be released this week. You may try
http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ or just wait for
the official release.

I have to take that back. Qt creator 4.11.1 still ships Qbs 1.15.0. The tag
was unfortunately made from an older commit. However,
http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ contains an
updated Qbs (1.15.1) containing the fix. We are aiming for Qbs 1.16.0
together with Qt Creator 4.12.0.

Plus, I suppose, an actual qbs 1.15.1 release with Creator 4.11.2.


Christian
___
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


Re: [Qbs] Construction project.buildDirectory

2020-02-06 Thread Christian Kandeler
On Thu, 6 Feb 2020 16:08:42 +0100
Richard Weickelt  wrote:

> > sorry for breaking this. The issue has been fixed by
> > https://codereview.qt-project.org/c/qbs/qbs/+/289271 and the fix will be in
> > Qt Creator 4.11.1 which is about to be released this week. You may try
> > http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ or just wait for
> > the official release.
> 
> I have to take that back. Qt creator 4.11.1 still ships Qbs 1.15.0. The tag
> was unfortunately made from an older commit. However,
> http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ contains an
> updated Qbs (1.15.1) containing the fix. We are aiming for Qbs 1.16.0
> together with Qt Creator 4.12.0.

Plus, I suppose, an actual qbs 1.15.1 release with Creator 4.11.2.


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


Re: [Qbs] Construction project.buildDirectory

2020-02-06 Thread Richard Weickelt
> sorry for breaking this. The issue has been fixed by
> https://codereview.qt-project.org/c/qbs/qbs/+/289271 and the fix will be in
> Qt Creator 4.11.1 which is about to be released this week. You may try
> http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ or just wait for
> the official release.

I have to take that back. Qt creator 4.11.1 still ships Qbs 1.15.0. The tag
was unfortunately made from an older commit. However,
http://download.qt.io/snapshots/qtcreator/4.11/4.11.1/187/ contains an
updated Qbs (1.15.1) containing the fix. We are aiming for Qbs 1.16.0
together with Qt Creator 4.12.0.

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