Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

[Allan Sandfeld Jensen]

On Montag, 18. Dezember 2017 18:53:55 CET Toan Pham wrote:
> "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine
> /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 45, in
> check_call
> subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 535, in check_call
> retcode = call(*popenargs, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 522, in call
> return Popen(*popenargs, **kwargs).wait()
>   File "/usr/lib/python2.7/subprocess.py", line 709, in __init__
> errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
> Project ERROR: GN build error!
> make[3]: *** [sub-gn-pro-make_first] Error 3
> make[3]: Leaving directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine
> /src/buildtools' make[2]: *** [sub-buildtools-make_first] Error 2
> make[2]: Leaving directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine
> /src' make[1]: *** [sub-src-make_first] Error 2
> make[1]: Leaving directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine
> '
> 
> 
> 
> Please let me know if you know what went wrong w/ the second build.
> 
> 
Looks like it expects ninja to be installed, but cant launch it. Check your 
configure output and see if it detected system ninja and you have ninja 
installed.

'Allan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] atomic commits across submodules

[Oswald Buddenhagen]

On Mon, Dec 18, 2017 at 09:22:31AM -0500, Adam Treat wrote:
> 3) Private API being changed out from under
>
3a) yet unreleased public api being revised.

there is just no reasonable way to claim that the pain inflicted by the
5-stage workaround is a good thing. it's a barely acceptable thing given
the constraint of atomic commits being unrealistic for the time being.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

[Michal Klocek]

Hi

It looks like the build can not proceed because of lack of working
ninja. Qt configure detects system ninja, and in case it does not work
builds internal one. In case for some reason this failed you can
still force the build to use internal ninja with configure option:

-no-feature-webengine-system-ninja

Br

Michal

On 12/18/2017 06:53 PM, Toan Pham wrote:
> Thiago,
> 
> 
> I am running two parallel builds at the moment, and they are:
> 
> 
> 1.  32 bit LXC container (ubuntu 16.04 32bit)
>  The build is still compiling chronium web-engine for the last an hr
> and a half.  So far, I haven't had much problem w/ this one except that
> I had to comment out a few lines in qtwebengine/qtwebengine.pro
>  to get the build started.
> 
> 
> 
> 2.  32bit inside T2SDE sandbox (ref. http://t2sde.org)
> 
>   This build stopped here:
> 
> make[4]: Entering directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
> make[4]: Nothing to be done for `first'.
> make[4]: Leaving directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
> ( test -e Makefile.configure_target ||
> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/bin/qmake
> -o Makefile.configure_target
> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools/configure_target.pro
>  ) && make -f Makefile.configure_target
> make[4]: Entering directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
> make[4]: Nothing to be done for `first'.
> make[4]: Leaving directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
> ( test -e Makefile.gn ||
> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/bin/qmake
> -o Makefile.gn
> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools/gn.pro
>  ) && make -f Makefile.gn
> Building gn manually in a temporary directory for bootstrapping...
> Traceback (most recent call last):
>   File
> "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
> line 855, in 
> sys.exit(main(sys.argv[1:]))
>   File
> "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
> line 127, in main
> return run_build(build_dir, options)
>   File
> "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
> line 74, in run_build
> build_gn_with_ninja_manually(tempdir, options)
>   File
> "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
> line 220, in build_gn_with_ninja_manually
> check_call(cmd)
>   File
> "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
> line 45, in check_call
> subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 535, in check_call
> retcode = call(*popenargs, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 522, in call
> return Popen(*popenargs, **kwargs).wait()
>   File "/usr/lib/python2.7/subprocess.py", line 709, in __init__
> errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
> Project ERROR: GN build error!
> make[3]: *** [sub-gn-pro-make_first] Error 3
> make[3]: Leaving directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
> make[2]: *** [sub-buildtools-make_first] Error 2
> make[2]: Leaving directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src'
> make[1]: *** [sub-src-make_first] Error 2
> make[1]: Leaving directory
> `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine'
> 
> 
> 
> Please let me know if you know what went wrong w/ the second build. 
> 
> 
> thanks,
> 
> TP
> 
> 
> On Mon, Dec 18, 2017 at 11:39 AM, Thiago Macieira
> > wrote:
> 
> On Monday, 18 December 2017 07:46:24 PST Toan Pham wrote:
> > Hi,
> >
> > I am having multiple problems w/ building qt5.10 w/ webengine support 
> for
> > linux 32bit.  Before I proceed further down that road, I would like to 
> know
> > if there's a pre-built version of qt5.10.0 w/ webengine for linux 32bit
> > somewhere?
> 
> There isn't. Linux 32-bit is uncommon enough these days that it's
> not worth
> spending CPU time building for it.
> 
> Please report your build issues. I did check a few 

Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

[Thiago Macieira]

On Monday, 18 December 2017 09:53:55 PST Toan Pham wrote:
> 1.  32 bit LXC container (ubuntu 16.04 32bit)
>  The build is still compiling chronium web-engine for the last an hr
> and a half.  So far, I haven't had much problem w/ this one except that I
> had to comment out a few lines in qtwebengine/qtwebengine.pro to get the
> build started.

Can you share what those were?

> 2.  32bit inside T2SDE sandbox (ref. http://t2sde.org)
> 
>   This build stopped here:
> 
> "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine
> /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 220, in
> build_gn_with_ninja_manually
> check_call(cmd)
>   File
> "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine
> /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 45, in
> check_call
> subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 535, in check_call
> retcode = call(*popenargs, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 522, in call
> return Popen(*popenargs, **kwargs).wait()
>   File "/usr/lib/python2.7/subprocess.py", line 709, in __init__
> errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
> Project ERROR: GN build error!

> Please let me know if you know what went wrong w/ the second build.

Some file is missing or failed to be build. Sorry, I don't have the chromium 
sources in my checkout so I can't tell what it's looking for. Given that you 
have one build working and one not, it's very likely this sandbox is missing 
some required tool.

Look into that bootstrap.py file to find out what it tried to run.

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

Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

[Toan Pham]

Thiago,


I am running two parallel builds at the moment, and they are:


1.  32 bit LXC container (ubuntu 16.04 32bit)
 The build is still compiling chronium web-engine for the last an hr
and a half.  So far, I haven't had much problem w/ this one except that I
had to comment out a few lines in qtwebengine/qtwebengine.pro to get the
build started.



2.  32bit inside T2SDE sandbox (ref. http://t2sde.org)

  This build stopped here:

make[4]: Entering directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
make[4]: Nothing to be done for `first'.
make[4]: Leaving directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
( test -e Makefile.configure_target ||
/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/bin/qmake
-o Makefile.configure_target
/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools/
configure_target.pro ) && make -f Makefile.configure_target
make[4]: Entering directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
make[4]: Nothing to be done for `first'.
make[4]: Leaving directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
( test -e Makefile.gn ||
/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/bin/qmake
-o Makefile.gn
/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools/
gn.pro ) && make -f Makefile.gn
Building gn manually in a temporary directory for bootstrapping...
Traceback (most recent call last):
  File
"/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
line 855, in 
sys.exit(main(sys.argv[1:]))
  File
"/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
line 127, in main
return run_build(build_dir, options)
  File
"/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
line 74, in run_build
build_gn_with_ninja_manually(tempdir, options)
  File
"/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
line 220, in build_gn_with_ninja_manually
check_call(cmd)
  File
"/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py",
line 45, in check_call
subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 535, in check_call
retcode = call(*popenargs, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 522, in call
return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 709, in __init__
errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
Project ERROR: GN build error!
make[3]: *** [sub-gn-pro-make_first] Error 3
make[3]: Leaving directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools'
make[2]: *** [sub-buildtools-make_first] Error 2
make[2]: Leaving directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src'
make[1]: *** [sub-src-make_first] Error 2
make[1]: Leaving directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine'



Please let me know if you know what went wrong w/ the second build.


thanks,

TP


On Mon, Dec 18, 2017 at 11:39 AM, Thiago Macieira  wrote:

> On Monday, 18 December 2017 07:46:24 PST Toan Pham wrote:
> > Hi,
> >
> > I am having multiple problems w/ building qt5.10 w/ webengine support for
> > linux 32bit.  Before I proceed further down that road, I would like to
> know
> > if there's a pre-built version of qt5.10.0 w/ webengine for linux 32bit
> > somewhere?
>
> There isn't. Linux 32-bit is uncommon enough these days that it's not worth
> spending CPU time building for it.
>
> Please report your build issues. I did check a few days ago that
> qtwebengine
> does not explicitly block 32-bit builds, so it should have worked.
>
> Please make sure you have a 64-bit linker. Also make sure you have gold
> available, it's possible that the regular BFD blows up due to memory use.
>
> --
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

[Thiago Macieira]

On Monday, 18 December 2017 07:46:24 PST Toan Pham wrote:
> Hi,
> 
> I am having multiple problems w/ building qt5.10 w/ webengine support for
> linux 32bit.  Before I proceed further down that road, I would like to know
> if there's a pre-built version of qt5.10.0 w/ webengine for linux 32bit
> somewhere?

There isn't. Linux 32-bit is uncommon enough these days that it's not worth 
spending CPU time building for it.

Please report your build issues. I did check a few days ago that qtwebengine 
does not explicitly block 32-bit builds, so it should have worked.

Please make sure you have a 64-bit linker. Also make sure you have gold 
available, it's possible that the regular BFD blows up due to memory use.

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

[Development] 32bit linux build of qt5.10.0 w/ webengine

[Toan Pham]

Hi,

I am having multiple problems w/ building qt5.10 w/ webengine support for
linux 32bit.  Before I proceed further down that road, I would like to know
if there's a pre-built version of qt5.10.0 w/ webengine for linux 32bit
somewhere?


thank you and have a good day,

TP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] atomic commits across submodules

[Adam Treat]

On 12/18/2017 05:24 AM, Jędrzej Nowacki wrote:

On czwartek, 7 grudnia 2017 12:17:16 CET Adam Treat wrote:

Hi,

I think it is high time that we fix the underlying problem: supporting
atomic commits across submodules.

As I'm not against the idea, I'm not really fan of it either. The problem with
atomic commits across submodules is that they encourage API breakages. Without
supporting both code paths even for a little while, one is not aware of the
pain that our users needs to go through every time we break API.


So your position is we shouldn't need atomic commits across submodules 
because the changes that are leading to breakage are themselves the 
problem. Let's examine types of changes:


1) Build system changes that require cross-module modifications
2) New public API in base module where dependent module takes advantage 
of it

3) Private API being changed out from under
4) Merges of the above 3 types from release branches to dev

Of these, only #2 should be solvable without atomic commits. In that 
case, we can introduce API first and when it is integrated, only then 
update dependent modules. This is still a problem for #4 though, but 
more about that later.


For the other types, atomic commits are at least sometimes going to be 
required. Right now, we are experiencing breakage. And it *is* painful. 
But I have not seen a postmortem of said breakages that shows the 
current processes are up to preventing such breakage. Maybe the answer 
is to move away from private API and a build system that does not need 
to be bootstrapped from Qt...


Now, back to #4, I do know that those responsible for merging from 
release branches into dev face a mind field of cross-module 
modifications. Consider #2 again and say such a change across modules 
has made it into release branches. It is my understanding that it is 
*just such a set of changes* that led to Liang Qi's request to add 
labels to API changes because the ordering info gets lost.  Merges from 
release to dev are going to be problematic until we have some way of 
ensuring cross-module dependencies are handled.


Which is why I propose that we stop merging from release to dev and 
require all changes to hit dev first. But, more on that in another email 
thread later. Maybe after the holidays ;)



Once this is done we should revert our CI to test changes against latest
version of all modules.

No. First, how these two are connected, that is a big jump to a solution,
without providing reasoning. I know that you didn't know about the fact that
we pin submodules in qt5 and you got burned by this. That __is__ an argument,
but an alternative solution would be a better documentation or UI.  Second,
the most important, that doesn't scale. By compiling against latest Qt5 we
reduced CI load by ~80%.


Fair enough, let's table this. I have more to say about this, but it 
really is related to my suggestion above. Again, more about that later.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dropping of MSVC 2013

[Tuukka Turunen]

Hi,

Akseli will check the percentages from Qt 5.10 online installer later this 
week. 

Yours,

Tuukka

On 16/12/2017, 18.25, "Development on behalf of Thiago Macieira" 
 wrote:

On Wednesday, 8 November 2017 10:57:32 PST Alex Blasche wrote:
> Sorry, no. As mentioned during the contributor summit, this decision is
> tabled until we have the 5.10 download figures.

Any numbers now?

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


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] atomic commits across submodules (was: Suggestion to add labels when changing API)

[Jędrzej Nowacki]

On czwartek, 7 grudnia 2017 12:17:16 CET Adam Treat wrote:
> Hi,
> 
> I think it is high time that we fix the underlying problem: supporting
> atomic commits across submodules.
As I'm not against the idea, I'm not really fan of it either. The problem with 
atomic commits across submodules is that they encourage API breakages. Without 
supporting both code paths even for a little while, one is not aware of the 
pain that our users needs to go through every time we break API. 

Even private API modifications have side effects. If you are working in qtbase 
then it is easy, but otherwise you are forced to recompile quite often or risk 
debugging subtle binary incompatibilities. It is not as crazy as during qt5.0 
but still happens.

In addition we were thinking about splitting submodules even more. Reduce 
amount of private API usage or even make them use only public API (quite nice 
but a controversial dream, please do not start discussion about that now :-) 
). Make them more independent libraries, which would have many positive 
aspects.

If you keep all these in mind, cross sumodule modifications are not encouraged 
and our process was never optimized for the case. Just to be very clear if you 
want to simplify changing many submodules at once, then you would get my full 
support, but keep in mind that it should not be disruptive nor for other Qt 
developers nor for Qt users.

> Once this is done we should revert our CI to test changes against latest
> version of all modules. 
No. First, how these two are connected, that is a big jump to a solution, 
without providing reasoning. I know that you didn't know about the fact that 
we pin submodules in qt5 and you got burned by this. That __is__ an argument, 
but an alternative solution would be a better documentation or UI.  Second, 
the most important, that doesn't scale. By compiling against latest Qt5 we 
reduced CI load by ~80%.

> * Adopt something like Google's repo tool:
> https://code.google.com/archive/p/git-repo/
> * Stop using submodules and use a monolithic repo
> * Git subtree
> * Implement atomic commit across submodules not in Git, but in the
> gerrit/COIN layer so that COIN effectively locks integrations until
> commits that span submodules are finished
> * Something else?
I think there is nothing in our infrastructure that would block us from 
implementing atomic cross submodules commits. It is matter of Coin calling few 
more functions.

Cheers,
  Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development