[Qbs] qbs-autoproject

[resurrection at centrum.cz]

> A desirable feature here would be to be able to control the order in 
> witch the match are done, this way one could, for example, put specific 
> patterns at the top, and catch-all at the bottom.

The items are prioritized in order of their definition. I believe I do mention that somewhere in the Readme but it is way too long. If you look at the default patterns you will notice that static lib item indeed catches all that was not matched by any previous. So this is the feature already.

> I might open an issue on that one.

Yes please open the issue about the open files.

> I got it, but why would you need to provide a path to Qt? Are you bypassing qbs-setup-qt and qmake? > If it's just an example, I think using 'Qt' is misleading.

Path to Qt is part of Qt.core module that is only available in Product items. It is not accessible from Project. How do I know? I asked here and was told so. :-) So unfortunately it needs to be like this.


> And a test framework? Ah, yeah, a JS library as well! ;)

Trust me, I would in a heart beat. But the idea was to use self contained single file that does not rely on anything outside that file or QBs itself.

> Which lead me to the use of 'path' for the user's item input files, I 
> would prefer to use the explicit 'files' property. This could be solved 
> with a filterOut at the writer stage, but this should actually be done 
> earlier, b/c it does impact the dependency analysis.

You can very easily change it yourself (list of files is in project.product.files). However the whole point of the paths and wildcards is that you do not need to rescan the whole project when adding/removing files - only when changing whole projects or in need to update dependencies. But using list of specific files is certainly more traditional. I might add it as option.

______________________________________________________________
> Od: Christian Gagneraud <chgans at gmail.com>
> Komu: resurrection at centrum.cz, qbs at qt-project.org
> Datum: 28.10.2017 15:19
> Předmět: Re: [Qbs] qbs-autoproject
>
On 28/10/17 20:02, resurrection at centrum.cz wrote:
> We have discussed some configuration issues via separate e-mail but
> few things worth pointing out here:
> 
> - I should likely call close() explicitly after reading a file. One
> gets spoiled from QFile's destructor. :-) That might alleviate the
> too many open files issue. I reckon it ultimately hits the OS limit
> on open file handles otherwise.

Yes, Ubuntu has tight limits, but so far it has always pointed me to a 
defect of some sort. From an operating-system point of view, 
qbs-autoproject is consuming too many file descriptors. And this usually 
means 'leaks'.

I might open an issue on that one.

I'll try to remove the contentPattern in the 'items' property too, 
hopefully there won't be any needs to open all the files anymore.

I only need Library, Application and UnitTest items that i can match by 
names. I do have other items, but i would like to ignore them for the 
moment.

A desirable feature here would be to be able to control the order in 
witch the match are done, this way one could, for example, put specific 
patterns at the top, and catch-all at the bottom.

In my case, i would like to match ignored first, then tests, then apps, 
everything else becomes library.
It's not clear to me which stage of the pipeline is affected by the 
configuration probe and how a given stage (successive probes) is affected.

> - modules are for external dependencies like Qt or your custom made
> modules. The path is the one I use for Qt, you should put your path
> or remove it altogether if your project is not using Qt.

I got it, but why would you need to provide a path to Qt? Are you 
bypassing qbs-setup-qt and qmake?
If it's just an example, I think using 'Qt' is misleading.

> - As mentioned the other issues are to do with configuration of the
> patterns as the described project is fairly standard.
> 
> - I have tried it on legacy code base of 400+ products without
> optimizing or ignoring any patterns and while it took long the
> results seemed reasonable especially considering how messy it is.

Glad to hear it worked on a legacy code base, I have a similar situation.

> 
> I will look into the performance issue for sure. And the readme
> should really be turned into the wiki.

And a test framework? Ah, yeah, a JS library as well! ;)

I'm just teasing, your project is great, I like very much the 'pipeline' 
approach, and the use of Qbs to boostrap a Qbs project is like the 
cherry on the cake!

What if each stage of the pipeline had it's own configuration? Including 
an option to simply pass through. Or even crasier, a JSON or QML file in 
'.qbs-autoproject/' that defines the pipeline itself.

Anyway, in my case, I have two choices:
- parse msvs solution and project files, digest, generate
- scan the filesystem, digest, generate

The msvs is moving to "property files" (MS crap that make you feel 
you're solving problems), so i would like to implement a real XML 
parser, ideally in Qt/C++, but python will do in the first place.
It's a vast subject, with very long meanders...

The filesystem approach is interesting too, but it will pick up zombie 
cpp units and headers, I think i have black lists somewhere! ;)

Which lead me to the use of 'path' for the user's item input files, I 
would prefer to use the explicit 'files' property. This could be solved 
with a filterOut at the writer stage, but this should actually be done 
earlier, b/c it does impact the dependency analysis.

It would be great too to make the acyclic test failure a warning or an 
error. One might be interested to know if the test fails or not while 
using an 'internal' safety dependency-tracking mechanism.

I do not know how you implemented the dependency tracking, thinking that 
you did it in JS simply blows my mind (I'm not a JS guy).
Having said that, dependency tracking is more than C pre-processor stuff.

Chris