Re: [Development] syncqt.pl in C++
> 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 <oliv...@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 > 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] syncqt.pl in C++
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. 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). 3. > The general idea is kind of following that of the Gradle wrapper, where any > project that uses the Gradle build system also can include a standard wrapper > script which obtains and bootstraps the build system itself before building > your project, allowing ANY project based on that build system to be "zero > dependencies". git clone & go, the system figures out the rest as much as it > can. I'm developing similar system that is based on CMake named C++ Archive Network [2]. That's why I asked the original question. Cppan uses simple declarative (YAML) syntax plus custom cmake insertions. Cppan in some sences is similar to npm, cocoapods and some other language package managers. You point your dependencies to CPPAN and it downloads and bootstraps them for you in any config you requested. You can pass any option or link flags to all deps. They are able to inherit everything if you want to. Static/shared/mt/md/32/64/different MSVCs/compilers/cmake generators (including ninja - WIP)/build caching and much more included. As a result we get simple crosscompiling. CPPAN is crossplatform, handles package versions, dependencies, namespaces. You can register there and add your package. As PoC I've added tons of c/c++ world libraries and now it's Qt time [3,4]. qt.base.core, gui and widgets are added and working. I'm very close to single-shot (one command) building of simple widget apps (QML is just a question of time - few weeks). One-shotting of projects (building, installing, testing, your fav workflow here) is the main goal. Almost all of those packages are in 'pvt.cppan.demo' namespace. For official purposes org.* com.* could be used. E.g. org.qtproject.qt.*, org.boost.*, com.intel.* etc. They are similar to Java, C#? namespaces. More info you can find on the site. Good doc is still in progress. As not a toy project CPPAN is currently used to build tesseract-OCR on Windows [5]. Also cppan is already self-hosted today. [1] https://github.com/egorpugin/syncqt/blob/master/syncqt.cpp [2] https://cppan.org/ [3] https://cppan.org/projects/pvt.cppan.demo.qtproject [4] https://cppan.org/pvt.cppan.demo.qtproject.qt.base.core [5] https://github.com/tesseract-ocr/tesseract -- Egor Pugin On 9 March 2017 at 22:07, Adam Treat <adam.tr...@qt.io> wrote: > > > On 03/07/2017 03:54 PM, Thiago Macieira wrote: >> >> Same here, though I have also to concede that breaking the status quo (to >> quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name >> another >> Trolltech project that had nothing to do with qt -- was a couple of orders >> of >> magnitude better than the tools that existed at the time (distcc). >> Icecream/ >> icecc came about only because TB wasn't open source, but every now and >> then I >> miss TB2 features that icecc doesn't have. TB3 would have been even >> better. >> >> Maybe qbs will be another such leapfrog. I can't fault TQtC for trying. > > > Speaking of distributed compilers... if QBS had built-in > icecream/TeamBuilder like functionality I would *love* this. It could even > bundle the tarball itself since it has the complete recipe for all the tools > necessary, the translation unit and everything in addition to create the > object file. > > That'd be one compelling feature for me. > > _______ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Egor Pugin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] syncqt.pl in C++
I see. Thanks. On 7 March 2017 at 01:32, Jake Petroules <jake.petrou...@qt.io> wrote: > >> On Mar 6, 2017, at 1:51 PM, Thiago Macieira <thiago.macie...@intel.com> >> wrote: >> >> Em segunda-feira, 6 de março de 2017, às 21:25:48 CET, Egor Pugin escreveu: >>> Hi, >>> >>> I'm experimenting with own builds of qt and found that raw sources in >>> git repo (e.g. [1]) do not contain include dir. It is created by >>> bin/syncqt.pl, so we have a perl dependency. >> >> Yes, we do. We've had that dependency for 15 years. > > And it will go away once Qt moves to Qbs as its default build system in Qt 6. > >> >>> On later steps qt is built pretty good without any serious issues. >>> >>> Is there any attempts to rewrite syncqt.pl in c++? >> >> No. > > It will be "rewritten" (although the replacement will not be a direct > translation) in JavaScript when Qt moves to Qbs. > >> >>> Maybe someone, who tried to perform cmake-based build of qt, >>> investigated this question? >>> Could it be useful at all? >> >> I don't think we'll accept it. > > No, we won't. Qbs. ;) > >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petrou...@qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Egor Pugin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] syncqt.pl in C++
Hi, I'm experimenting with own builds of qt and found that raw sources in git repo (e.g. [1]) do not contain include dir. It is created by bin/syncqt.pl, so we have a perl dependency. On later steps qt is built pretty good without any serious issues. Is there any attempts to rewrite syncqt.pl in c++? Maybe someone, who tried to perform cmake-based build of qt, investigated this question? Could it be useful at all? [1] http://code.qt.io/cgit/qt/qtbase.git/tree/ -- Egor Pugin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problems compiling QtWebEngine in 5.8.0 beta
Probably file path is too long.
MS improved situation since win10.1607 (up to 32k symbols) but almost
every program today (even from MS) is not able to handle such paths.
They require special handling.
See
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
for more info.
I had same issues with cmake+msbuild invocations.
On 9 November 2016 at 23:46, Harald Vistnes <harald.vist...@gmail.com> wrote:
> Hi,
>
> I'm having problems compiling 5.8.0 beta from source. It fails when making
> qtwebengine.
>
>
> D:\qt-everywhere-opensource-src-5.8.0-beta\qtwebengine\src\3rdparty\ninja\ninja.exe
> -C
> D:/qt-everywhere-opensource-src-5.8.0-beta/qtwebengine/src/core/Release_x64
> ninja: Entering directory
> `D:/qt-everywhere-opensource-src-5.8.0-beta/qtwebengine/src/core/Release_x64'
> ninja: error:
> WriteFile(obj\src\3rdparty\chromium\third_party\WebKit\Source\core\gen\blink\bindings\core\v8\webcore_generated.HTMLImageElementOrHTMLVideoElementOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj.rsp):
> Unable to create file. No such file or directory
>
> ninja: build stopped: .
> NMAKE : fatal error U1077:
> 'D:\qt-everywhere-opensource-src-5.8.0-beta\qtwebengine\src\3rdparty\ninja\ninja.exe'
> : return code '0x1'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '(' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
>
> Environment:
> Windows 10
> VS2015 x64
> Windows 10 SDK
> ninja
>
> Any help would be appreciated.
>
> Thanks,
> Harald
>
>
>
> _______
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
--
Egor Pugin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
