On Tue, Mar 07, 2017 at 11:46:58AM +0100, Thiago Macieira wrote: > Em terça-feira, 7 de março de 2017, às 08:16:14 CET, Simon Hausmann escreveu: > > I for one would welcome a C++ rewrite of syncqt inside qmake to get rid of > > the perl dependency. However I do not have the authority to approve such a > > contribution. It is something we have talked about many times on the > > hallway. > i think i'd approve it at this point. however, i don't want a 1:1 port of the perl code, because sync.profile is kinda nuts, with multiple mostly redundant ways to specify things. also, perl isn't exactly the optimal input language for non-perl interpreters. a nice per-module json file would do.
> You have a chicken-and-the-egg problem here, as qmake depends on the headers > being generated by syncqt before it can be compiled. > it's not that bad. the bootstrapped build uses syncqt -minimal, which just collects the lowercase headers. this could be done adequately with sh and even cmd. > I read the OP's email as a request to write it in non-Qt C++ so we could drop > the Perl dependency. I don't think we want that, it's not worth the effort. > i also don't think it's *worth* it, especially with The New Build System (TM) looming not too far off. however, i'd be willing to review a relevant contribution - provided it's done competently enough that it doesn't have to go through dozens of tiresome rounds of review. > > Until we arrive in the promised land of a new build system, it would > > allow us to simplify our source packaging even further the moment we > > have it (syncqt C++). > > syncqt in qmake, yes, possibly. > > Rewrite it in non-Qt C++, please no. > i wouldn't be fundamentally opposed to stl, as the tool is small enough and self-contained. however, it seems stupid not to do it as part of qmake given that it already has the rudimentary c++ parser that's needed (currently used for dependency scanning). and the headers.pri file created by syncqt is meant for qmake consumption anyway ... another option is exposing c++ parser primitives from qmake and implementing the higher-level functionality in the qmake language. the value of this exercise would be a prototype for a possible implementation in qbs - a purely js-based implementation is somewhat slow-ish. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
