[Development] syncqt.pl in C++

Egor Pugin egor.pugin at gmail.com
Tue Mar 14 21:50:34 CET 2017


> You are replacing a perl dependency by a boost one. I'm not sure which one is worse.

That is reference implementation only. It's far far away of needed
shape to replace the perl script.
Some functions (enumerate_files) were taken from other libraries
including boost.

On 14 March 2017 at 17:23, Olivier Goffart <olivier at woboq.com> wrote:
> On Donnerstag, 9. März 2017 21:19:51 CET Egor Pugin wrote:
>> Hello again,
>>
>> Pretty long discussion is moved to build systems.
>> Here are some my general notes and brief presentation of my project.
>>
>> 1. For those who may be interested - my simple implementation of
>> syncqt.pl in C++ available here [1]. Works for me, tested and compiled
>> core, gui, widgets, prepared all other headers. Feel free to use it
>> for any purpose and contact me if you need.
>> [1] https://github.com/egorpugin/syncqt/blob/master/syncqt.cpp
>
> You are replacing a perl dependency by a boost one. I'm not sure which one is
> worse.
> Also, I don't see the implementation of enumerate_files (is it in the
> <primitives/filesystem.h> files that seem to be missing)
>
> So in order to go upstream we need to, at least: get rid of the boost
> dependency, and integrate so it can be built and run by the configure script.
>
> (Also it should compile with all supported compiler, that includes GCC 4.8
> which did not have std::regex IIRC)
>
>> 2. Build systems. Obvious BS candidate for many projects is cmake. We
>> see that it can handle big projects well (LLVM). Don't know much about
>> Qbs, but if will be (is) productive and extensible enough it may be
>> useful. Some other less spread build systems introduce heavy
>> dependencies (like python).
>
> About build system, I saw that Qt6 is mentioned.
> However, I would like to point out that a change in the build system is
> orthogonal to a change in the major version.
> I mean: We can change the Qt build system in any version of Qt we don't have
> to wait Qt6 for that.
> As long as qmake stays working for applications using it, of course. But then
> again, we can deprecate qmake within Qt5 life time  (we did it with QtScript/
> QtWebkit)
>
> Also, different modules could use different build system (That's already the
> case for qtwebengine)
>
>
> --
> Olivier
>
> Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



-- 
Egor Pugin



More information about the Development mailing list