Re: [Development] V8's location
On Wednesday, 4 de January de 2012 11.00.35, Kent Hansen wrote: Den 03. jan. 2012 15:51, skrev ext Kent Hansen: I created http://code.google.com/p/v8/issues/detail?id85 for the icc fix (note that I'm not allowed to submit patches :( ). Make sure to vote for it! ;) I'll import your patch into our tree for the time being. The issue was merged into http://code.google.com/p/v8/issues/detail?idh9, which links to http://software.intel.com/en-us/articles/compiler-reports-error-803-when-com piling-chromium-os-code/ This is a known issue that may be resolved in a future product update. ... could you poke the icc guys to fix it, maybe? :D I'm not sure it's an ICC bug at all, even though the ICC guys recognised it. They're probably just being nice and want to get 100% compatibility with GCC, even bug-to-bug compatibility. The file in question has: // Force instantiation of template instances class. // Please note this list is compiler dependent. The V8 guys recognise they're doing something non-standard. Anyway, this is the least of the problems. The current ICC version has a major parsing bug with the V8 source code that I reported but hasn't yet been solved. The bug report is apparently not public. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
Den 03. jan. 2012 22:07, skrev ext lars.kn...@nokia.com: On 1/3/12 5:45 PM, ext Oswald Buddenhagenoswald.buddenha...@nokia.com wrote: On Tue, Jan 03, 2012 at 01:45:27PM -0200, ext Thiago Macieira wrote: Configure already sets a default mkspec symlink that matches the target mkspec. Making it also create a symlink for default-host which matches the host platform would be easy. The tricky part is using that. You could specify the -spec default-host option when running configure, but last I checked with Marius (or was it still Sam?), you can't add that to the .pro file because it's too late. The spec file was already loaded by the time the .pro file is parsed. So my guess is this would be a major incursion into qmake to support the feature. correct. It would probably be easier, though uglier, to add a separate file that is read by qmake when it finds the .pro file. well, technically, there is no reason why that separate file could not be the .pro file itself: #pragma spec:default-host TARGET=lrelease ... pure beauty! :D Yes, something like this would be great. Can we please get it? We could even require this to be in the first line of the pro file to make things simple. The default would obviously use the target mkspec, so we'd only need to patch a few pro files. Cheers, Lars I created https://bugreports.qt.nokia.com/browse/QTBUG-23447 and made it a blocker for the move of v8. Regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
CONFIG(host, host|target) {
# Do host stuff
} else {
# Do target stuff
}
Might work, if you know the host or target mkspecs. However, for general
purpose we can introduce variables which contain these.
QMAKE_HOST_SPEC=host
QMAKE_TARGET_SPEC=target1 target2
for example..
--
.marius
-Original Message-
From: development-bounces+marius.storm-olsen=nokia.com@qt-
project.org [mailto:development-bounces+marius.storm-
olsen=nokia@qt-project.org] On Behalf Of Knoll Lars (Nokia-MP/Oslo)
Sent: Tuesday, January 03, 2012 9:21 AM
To: Hansen Kent (Nokia-MP/Oslo); development@qt-project.org
Subject: Re: [Development] V8's location
On 1/3/12 2:49 PM, ext Kent Hansen kent.han...@nokia.com wrote:
Den 01. jan. 2012 20:59, skrev ext simon.hausm...@nokia.com:
Whoever is going to do the work may first have to add support for host
builds in modules outside qtbase, in order to support v8 snapshots.
Simon
Hmm, I was getting ready to create a JIRA task (Add support for host
builds in modules outside qtbase), but then I noticed that
linguist/lrelease is still present in the part of the configure script
that handles the host-or-target mkspec selection:
*tools/bootstrap*|*tools/moc*|*tools/rcc*|*tools/uic*|*linguist/lrelease
*)
SPEC=$QMAKESPEC ;;
but lrelease lives in the qttools module now. So how is it built as a
host tool when cross-compiling? Is it hard-coded somewhere else or is
there already a general solution in place (too much New Year's optimism)?
Not sure how it works currently. But in general it'd be good if we can fix
this once and for all by adding proper cross compilation support to
qmake/configure. Something where you can specify host vs target in the
.pro file.
Cheers,
Lars
qtbase/mkspecs/features/qt_module_config.prf does
qtPrepareTool(QMAKE_LRELEASE, lrelease) and some more stuff, does it
still belong there?
Kent
___
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
On Tuesday, 3 de January de 2012 15.21.26, lars.kn...@nokia.com wrote: Not sure how it works currently. But in general it'd be good if we can fix this once and for all by adding proper cross compilation support to qmake/configure. Something where you can specify host vs target in the .pro file. Configure already sets a default mkspec symlink that matches the target mkspec. Making it also create a symlink for default-host which matches the host platform would be easy. The tricky part is using that. You could specify the -spec default-host option when running configure, but last I checked with Marius (or was it still Sam?), you can't add that to the .pro file because it's too late. The spec file was already loaded by the time the .pro file is parsed. So my guess is this would be a major incursion into qmake to support the feature. It would probably be easier, though uglier, to add a separate file that is read by qmake when it finds the .pro file. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
On Tue, Jan 03, 2012 at 01:45:27PM -0200, ext Thiago Macieira wrote: Configure already sets a default mkspec symlink that matches the target mkspec. Making it also create a symlink for default-host which matches the host platform would be easy. The tricky part is using that. You could specify the -spec default-host option when running configure, but last I checked with Marius (or was it still Sam?), you can't add that to the .pro file because it's too late. The spec file was already loaded by the time the .pro file is parsed. So my guess is this would be a major incursion into qmake to support the feature. correct. It would probably be easier, though uglier, to add a separate file that is read by qmake when it finds the .pro file. well, technically, there is no reason why that separate file could not be the .pro file itself: #pragma spec:default-host TARGET=lrelease ... pure beauty! :D ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
On 1/3/12 5:45 PM, ext Oswald Buddenhagen oswald.buddenha...@nokia.com wrote: On Tue, Jan 03, 2012 at 01:45:27PM -0200, ext Thiago Macieira wrote: Configure already sets a default mkspec symlink that matches the target mkspec. Making it also create a symlink for default-host which matches the host platform would be easy. The tricky part is using that. You could specify the -spec default-host option when running configure, but last I checked with Marius (or was it still Sam?), you can't add that to the .pro file because it's too late. The spec file was already loaded by the time the .pro file is parsed. So my guess is this would be a major incursion into qmake to support the feature. correct. It would probably be easier, though uglier, to add a separate file that is read by qmake when it finds the .pro file. well, technically, there is no reason why that separate file could not be the .pro file itself: #pragma spec:default-host TARGET=lrelease ... pure beauty! :D Yes, something like this would be great. Can we please get it? We could even require this to be in the first line of the pro file to make things simple. The default would obviously use the target mkspec, so we'd only need to patch a few pro files. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
Indeed, that looks elegant :) Simon -- Sent from my Nokia N903.01.12 17:46 skrev Buddenhagen Oswald (Nokia-MP/Berlin): On Tue, Jan 03, 2012 at 01:45:27PM -0200, ext Thiago Macieira wrote: Configure already sets a default mkspec symlink that matches the target mkspec. Making it also create a symlink for default-host which matches the host platform would be easy. The tricky part is using that. You could specify the -spec default-host option when running configure, but last I checked with Marius (or was it still Sam?), you can't add that to the .pro file because it's too late. The spec file was already loaded by the time the .pro file is parsed. So my guess is this would be a major incursion into qmake to support the feature. correct. It would probably be easier, though uglier, to add a separate file that is read by qmake when it finds the .pro file. well, technically, there is no reason why that separate file could not be the .pro file itself: #pragma spec:default-host TARGET=lrelease ... pure beauty! :D ___ 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] V8's location
Whoever is going to do the work may first have to add support for host builds in modules outside qtbase, in order to support v8 snapshots. Simon -- Sent from my Nokia N930.12.11 09:09 skrev ext Thiago Macieira: On Monday, 12 de December de 2011 19.34.21, Thiago Macieira wrote: On Monday, 12 de December de 2011 18.03.53, aaron.kenn...@nokia.com wrote: $ git reset --hard d28b6a024826aaa48a8b3e69c096d01c91aff2c9 Checking out files: 100% (894/894), done. HEAD is now at d28b6a0 Add flag to avoid breakpoint relocation The Qt v8 repo is a clone of the official v8 git repo, so we preserve whatever formatting Google has chosen. Doesn't mean they have sane procedures... But that's yet another reason for it to move out of qtbase. People are far less likely to modify the qt5.git repository than qtbase.git. Can we PLEASE make the move happen? I'm tired of every week chasing which commit in my 100-commit-on-top-of-origin master branch included src/3rdparty/v8 by accident. At the very least, please apply the two attached patches as soon as possible. (V8 isn't subject to the CLA and I'm not sending patches to Google either) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
This would help a bit for one problem. But the other problem is that it makes working with qtbase harder because of the submodule. (while comitting you have to remember not to commit the v8 stuff) I think having a submodule in qtbase causes a lot of trouble for very little gain. Another issue is that the V8 repository has files checked in with CRLF line endings (intentionally or otherwise), which makes git think there is always a modified file if core.autocrlf=true in git config. Among other things, this blocks the git submodule update It can be worked around like this: $ git submodule update error: You have local changes to 'tools/visual_studio/d8_arm.vcproj'; cannot switch branches. Unable to checkout 'd28b6a024826aaa48a8b3e69c096d01c91aff2c9' in submodule path'src/3rdparty/v8' $ cd src/3rdparty/v8/ $ git reset --hard d28b6a024826aaa48a8b3e69c096d01c91aff2c9 Checking out files: 100% (894/894), done. HEAD is now at d28b6a0 Add flag to avoid breakpoint relocation Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
On Monday, 12 de December de 2011 18.03.53, aaron.kenn...@nokia.com wrote: $ git reset --hard d28b6a024826aaa48a8b3e69c096d01c91aff2c9 Checking out files: 100% (894/894), done. HEAD is now at d28b6a0 Add flag to avoid breakpoint relocation The Qt v8 repo is a clone of the official v8 git repo, so we preserve whatever formatting Google has chosen. Doesn't mean they have sane procedures... But that's yet another reason for it to move out of qtbase. People are far less likely to modify the qt5.git repository than qtbase.git. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
Stephen Kelly said: On Wednesday, November 09, 2011 13:54:37 Thiago Macieira wrote: On Friday, 28 de October de 2011 12:38:38 lars.kn...@nokia.com wrote: We've been moving this lib quite a bit already. If we move it again, I'd prefer it would end up at it's final location. The move was done before we had the decision to keep QtCore independent of V8 and to separate the QJS* classes and the QML engine into it's own module. With the above decision it might make sense to move V8, the QJS* classes and the QML engine all into the same shared library. Kent Aaron, any thoughts? Since they don't seem to have an opinion, can we please move it to top-level inside qt5.git? I've just caught a bad commit in my tree that updates the commit link to v8 and I'm trying to fix it with an interactive rebase. Bump. This is a recurring problem with newcomers trying to build qtbase. They don't know to do the git submodule magic or use -no-v8, so the build fails. I think this can be easily mitigated by having qmake check if the sources exist, rather than simply assuming that they do. e.g. http://codereview.qt-project.org/10934 . ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
On Friday, 28 de October de 2011 12:38:38 lars.kn...@nokia.com wrote: We've been moving this lib quite a bit already. If we move it again, I'd prefer it would end up at it's final location. The move was done before we had the decision to keep QtCore independent of V8 and to separate the QJS* classes and the QML engine into it's own module. With the above decision it might make sense to move V8, the QJS* classes and the QML engine all into the same shared library. Kent Aaron, any thoughts? Since they don't seem to have an opinion, can we please move it to top-level inside qt5.git? I've just caught a bad commit in my tree that updates the commit link to v8 and I'm trying to fix it with an interactive rebase. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
On Monday, 24 de October de 2011 14:15:38 Thiago Macieira wrote: Isn't the right solution then to get your patch either upstream or into the Qt copy? Yes and no. Yes, I should get my fixes into the Qt copy (at least). But it's not a full solution since very often I have pending changes or in-progress development that I committed. [...] But please move the submodule to qt5.git. Can we move the submodule? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
