Re: [Development] syncqt.pl in C++

> On Mar 18, 2017, at 7:33 PM, Kuba Ober wrote: > > cmake is a "build system" in the same sense as qmake is: it only generates > output for the real build tool to deal with. Of this, in practice, ninja is > the only tool that won't make you grow white hair waiting for it to finish. > And even

Re: [Development] syncqt.pl in C++

> 7 mars 2017 kl. 15:54 skrev Thiago Macieira : > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore escreveu: >>> The Qt Company has now very recently made a decision to now go and invest >>> the man power required to turn qbs into a product we can fully support in >>> the fut

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:2

Re: [Development] syncqt.pl in C++

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

Re: [Development] syncqt.pl in C++

On sexta-feira, 10 de março de 2017 11:08:21 PST Jake Petroules wrote: > We never said we will continue to use QtScript *as-is*. When I said JSC, I > was talking about a modern version of JSC from the WebKit trunk, not the > last copy of it that was bundled with QtScript. For standards-compliance &

Re: [Development] syncqt.pl in C++

> On Mar 10, 2017, at 11:21 AM, André Pönitz wrote: > > On Fri, Mar 10, 2017 at 07:08:21PM +, Jake Petroules wrote: >> We never said we will continue to use QtScript *as-is*. When I said JSC, I >> was >> talking about a modern version of JSC from the WebKit trunk, not the last >> copy >> o

Re: [Development] syncqt.pl in C++

On Fri, Mar 10, 2017 at 07:08:21PM +, Jake Petroules wrote: > We never said we will continue to use QtScript *as-is*. When I said JSC, I was > talking about a modern version of JSC from the WebKit trunk, not the last copy > of it that was bundled with QtScript. For standards-compliance & featur

Re: [Development] syncqt.pl in C++

> On Mar 10, 2017, at 9:33 AM, Thiago Macieira > wrote: > > On sexta-feira, 10 de março de 2017 04:48:18 PST Joerg Bornemann wrote: >> No, but we have tried Duktape a year ago. >> I stopped working on a switch to Duktape because of three things: >> 1. C++-references to JS objects. One had to ma

Re: [Development] syncqt.pl in C++

On sexta-feira, 10 de março de 2017 04:48:18 PST Joerg Bornemann wrote: > No, but we have tried Duktape a year ago. > I stopped working on a switch to Duktape because of three things: > 1. C++-references to JS objects. One had to make sure that the engine > doesn't garbage collect what you're refer

Re: [Development] syncqt.pl in C++

On 09/03/2017 07:55, Thiago Macieira wrote: Have you tried the JerryScript interpreter? No, but we have tried Duktape a year ago. I stopped working on a switch to Duktape because of three things: 1. C++-references to JS objects. One had to make sure that the engine doesn't garbage collect wha

Re: [Development] syncqt.pl in C++

..@qt-project.org> on behalf of Sune Vuorela > *Sent:* Wednesday, March 8, 2017 11:53:17 AM > *To:* development@qt-project.org > > *Subject:* Re: [Development] syncqt.pl in C++ > On 2017-03-07, Lars Knoll wrote: > > This also makes qbs a natural choice to also use for Qt itse

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

Re: [Development] syncqt.pl in C++

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 th

Re: [Development] syncqt.pl in C++

> On Mar 9, 2017, at 2:47 AM, Mathias Hasselmann > wrote: > > > > Am 08.03.2017 um 21:23 schrieb Jake Petroules: >> 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 obta

Re: [Development] syncqt.pl in C++

On jueves, 9 de marzo de 2017 11:22:28 ART Konrad Rosenbaum wrote: > Hi, > > On Wed, March 8, 2017 21:23, Jake Petroules wrote: > > Personally, I also prefer a build process never touch the network, but the > > average developer isn't that picky and just wants to Get Things Done. > > The average

Re: [Development] syncqt.pl in C++

Am 08.03.2017 um 21:23 schrieb Jake Petroules: 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, allo

Re: [Development] syncqt.pl in C++

Hi, On Wed, March 8, 2017 21:23, Jake Petroules wrote: > Personally, I also prefer a build process never touch the network, but the > average developer isn't that picky and just wants to Get Things Done. The average test engineer is that picky and even worse! A test engineer expects to save a mi

Re: [Development] syncqt.pl in C++

Em quarta-feira, 8 de março de 2017, às 21:09:49 CET, Jake Petroules escreveu: > Right now we depend on JSC via QtScript (not V4) but that will change at > some point. We're not entirely sure of the solution yet; newer JSC vs V8 vs > V4 or another solution. Have you tried the JerryScript interpret

Re: [Development] syncqt.pl in C++

> On Mar 8, 2017, at 12:15 PM, Sune Vuorela wrote: > > On 2017-03-08, Jake Petroules wrote: >> I'm working on the qbs bootstrapping. The requirements will be: a C++11 com= >> piler. End of requirements. Seriously. Not even bash, if you don't mind typ= >> ing a couple commands manually. > > I d

Re: [Development] syncqt.pl in C++

On 2017-03-08, Jake Petroules wrote: > I'm working on the qbs bootstrapping. The requirements will be: a C++11 com= > piler. End of requirements. Seriously. Not even bash, if you don't mind typ= > ing a couple commands manually. I don't mind a bat script, a bash script or whatever is needed, but

Re: [Development] syncqt.pl in C++

development@qt-project.org Subject: Re: [Development] syncqt.pl in C++ On 2017-03-07, Lars Knoll wrote: > This also makes qbs a natural choice to also use for Qt itself, and I belie= > ve all the people that have worked and maintained Qt's build system over th= > e last few years are

Re: [Development] syncqt.pl in C++

On 2017-03-07, Lars Knoll wrote: > This also makes qbs a natural choice to also use for Qt itself, and I belie= > ve all the people that have worked and maintained Qt's build system over th= > e last few years are supporting this. Of course this requires that we can s= > how that qbs can be used t

Re: [Development] syncqt.pl in C++

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 suc

Re: [Development] syncqt.pl in C++

Em quarta-feira, 8 de março de 2017, às 11:37:43 CET, Kai Koehne escreveu: > I take the blame for not preparing the session properly then. Anyhow, it was > never intended as a decision forum in the first place. It couldn't have been. Only this mailing list is allowed to make decisions for the Qt

Re: [Development] syncqt.pl in C++

Cc: Thiago Macieira ; Qt development mailing > > list > > Subject: Re: [Development] syncqt.pl in C++ > > > > > > You're right. My wording above was misleading, I wasn't present > > myself. This is what I remembered people telli

Re: [Development] syncqt.pl in C++

> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Richard Moore > Sent: Tuesday, March 07, 2017 10:44 PM > To: Lars Knoll > Cc: Thiago Macieira ; Qt development mailing > list > Subject: Re: [Dev

Re: [Development] syncqt.pl in C++

André Somers (8 March 2017 06:18) > The stopping maintainance of qmake can't happen any time soon I'd > think. Not even from Qt6. There are too many Qt projects out there > depending on it. All the same, the sooner we can make the transition away from using it ourselves, the sooner we can retire q

Re: [Development] syncqt.pl in C++

Op 07/03/2017 om 22:43 schreef Richard Moore: > > > You're right. My wording above was misleading, I wasn't present > myself. This is what I remembered people telling me afterwards. > > Here are the session > notes: https://wiki.qt.io/Qt_build_systems_at_QtCon_2016 >

Re: [Development] syncqt.pl in C++

For what it's worth, as a Qt user, QBS was, last time I checked missing some features, like non-transitive compilatuons flags, platform support and documentation. That being said, in the past few years, I wrote some makefiles, some cmake projects. I've used WAF, qmake... QBS is the best C++ build

Re: [Development] syncqt.pl in C++

> > > You're right. My wording above was misleading, I wasn't present myself. > This is what I remembered people telling me afterwards. > > Here are the session notes: https://wiki.qt.io/Qt_ > build_systems_at_QtCon_2016 > > ​Yep, there's also a video. My recollection is that there was a small voca

Re: [Development] syncqt.pl in C++

On 7 Mar 2017, at 22:24, Richard Moore mailto:r...@kde.org>> wrote: On 7 March 2017 at 21:21, Lars Knoll mailto:lars.kn...@qt.io>> wrote: > On 7 Mar 2017, at 21:54, Thiago Macieira > mailto:thiago.macie...@intel.com>> wrote: > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard M

Re: [Development] syncqt.pl in C++

On 7 March 2017 at 21:21, Lars Knoll wrote: > > > On 7 Mar 2017, at 21:54, Thiago Macieira > wrote: > > > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore > escreveu: > >>> The Qt Company has now very recently made a decision to now go and > invest > >>> the man power require

Re: [Development] syncqt.pl in C++

> On 7 Mar 2017, at 21:54, Thiago Macieira wrote: > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore escreveu: >>> The Qt Company has now very recently made a decision to now go and invest >>> the man power required to turn qbs into a product we can fully support in >>> the f

Re: [Development] syncqt.pl in C++

Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore escreveu: > > The Qt Company has now very recently made a decision to now go and invest > > the man power required to turn qbs into a product we can fully support in > > the future. This decision comes from the fact that we see that

Re: [Development] syncqt.pl in C++

Em terça-feira, 7 de março de 2017, às 19:19:12 CET, Jake Petroules escreveu: > Let me clarify: internally at The Qt Company we made the decision that Qbs > will become the default build system for Qt 6. Technically the Qt Project > has not yet made that decision but once the formalities are gone t

Re: [Development] syncqt.pl in C++

On 7 March 2017 at 19:12, Lars Knoll wrote: > Hi, > > Thiago's right that there has not been a formal decision in the Qt project > about the build system to use for Qt 6. So saying qbs will be the build > system for Qt 6 is getting a bit ahead of things. > > But we have had many discussions in th

Re: [Development] syncqt.pl in C++

Hi, Thiago's right that there has not been a formal decision in the Qt project about the build system to use for Qt 6. So saying qbs will be the build system for Qt 6 is getting a bit ahead of things. But we have had many discussions in the past as well, where the result was that the people ma

Re: [Development] syncqt.pl in C++

> On Mar 7, 2017, at 8:47 AM, Wolfgang Baron wrote: > > On 7 Mar 2017, at 08:11, Thiago Macieira > wrote: > > > There has been no discussion of qbs. Therefore, there is no > > decision on what to use for Qt 6. It might be cmake or qmake. > > Then please start that discussion now. Qbs is a se

Re: [Development] syncqt.pl in C++

On 7 Mar 2017, at 08:11, Thiago Macieira wrote: There has been no discussion of qbs. Therefore, there is no decision on what to use for Qt 6. It might be cmake or qmake. Then please start that discussion now. Qbs is a secret weapon for all developers trying to do test driven development but

Re: [Development] syncqt.pl in C++

Em terça-feira, 7 de março de 2017, às 08:16:14 CET, Simon Hausmann escreveu: > Hi, > > 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

Re: [Development] syncqt.pl in C++

Hi, 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. Until we arrive in the promised land of a new build system, it

Re: [Development] syncqt.pl in C++

Em segunda-feira, 6 de março de 2017, às 23:32:42 CET, Jake Petroules escreveu: > > 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. There has been no discussion of qbs. Therefore, there is no decision on what

Re: [Development] syncqt.pl in C++

I see. Thanks. On 7 March 2017 at 01:32, Jake Petroules wrote: > >> On Mar 6, 2017, at 1:51 PM, Thiago Macieira >> 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 >>> g

Re: [Development] syncqt.pl in C++

> On Mar 6, 2017, at 1:51 PM, Thiago Macieira 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/sync

Re: [Development] syncqt.pl in C++

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

[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