[Qbs] qbs-autoproject

[Christian Gagneraud]

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