On 28/10/17 20:02, [email protected] 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
_______________________________________________
Qbs mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/qbs
