[Development] syncqt.pl in C++

[Oswald Buddenhagen]

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.