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 Buddenhagen" > 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
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 15:51, skrev ext Kent Hansen: > > I created http://code.google.com/p/v8/issues/detail?id=1885 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?id=689, which links to http://software.intel.com/en-us/articles/compiler-reports-error-803-when-compiling-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 Kent ___ 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
On 1/3/12 5:45 PM, "ext Oswald Buddenhagen" 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
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 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
CONFIG(, |) {
# Do stuff
} else {
# Do stuff
}
Might work, if you know the or mkspecs. However, for general
purpose we can introduce variables which contain these.
QMAKE_HOST_SPEC=
QMAKE_TARGET_SPEC=
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" 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 1/3/12 2:49 PM, "ext Kent Hansen" 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
Re: [Development] V8's location
Den 30. des. 2011 15:06, 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. Hey, there's even a task for it now: https://bugreports.qt.nokia.com/browse/QTBUG-23423 > 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) The mksnapshot issue has been fixed upstream in v8 version 3.8.1. We can use your patch until we rebase past that version. I created http://code.google.com/p/v8/issues/detail?id=1885 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. I will amend your patches so they link to the relevant upstream bugs/commits. Kent ___ 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 14.49.41, Kent Hansen wrote: > *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)? My guess is people cross-compiling won't build qttools in the first place. -- 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 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)?
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
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
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
>From 35464b4b92538ddad22c26ec2b021c68d2879066 Mon Sep 17 00:00:00 2001
From: Thiago Macieira
Date: Thu, 1 Sep 2011 11:30:40 +0200
Subject: [PATCH 1/2] Fix compilation with Intel CC.
---
src/objects.cc |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/objects.cc b/src/objects.cc
index 6a4eff9..040628c 100644
--- a/src/objects.cc
+++ b/src/objects.cc
@@ -11129,6 +11129,7 @@ template class Dictionary;
template class Dictionary;
+#ifndef __INTEL_COMPILER
template MaybeObject* Dictionary::Allocate(
int);
@@ -11203,7 +11204,7 @@ int Dictionary::NumberOfEnumElements();
template
int HashTable::FindEntry(uint32_t);
-
+#endif
// Collates undefined and unexisting elements below limit from position
// zero of the elements. The object stays in Dictionary mode.
--
1.7.6.4
>From 8884b0e7f529fd356acc637e98d1f285afbfe723 Mon Sep 17 00:00:00 2001
From: Thiago Macieira
Date: Mon, 5 Dec 2011 12:49:30 -0800
Subject: [PATCH 2/2] Make the snapshot creator output proper byte (0-255)
numbers
These numbers are stored in a "const byte[]" array. In C++11 mode, a
negative number like -1 cannot be automatically converted to an
unsigned char. So output only the proper unsigned numbers.
---
src/mksnapshot.cc |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mksnapshot.cc b/src/mksnapshot.cc
index bc0c2fc..c354f6d 100644
--- a/src/mksnapshot.cc
+++ b/src/mksnapshot.cc
@@ -109,10 +109,10 @@ class PartialSnapshotSink : public i::SnapshotByteSink {
if (j != 0) {
fprintf(fp, ",");
}
- fprintf(fp, "%d", at(j));
+ fprintf(fp, "%u", at(j));
}
}
- char at(int i) { return data_[i]; }
+ unsigned char at(int i) { return data_[i]; }
bool Compress(Compressor* compressor) {
ASSERT_EQ(-1, raw_size_);
raw_size_ = data_.length();
--
1.7.6.4
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, December 12, 2011 10:30:31 you wrote: > 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 . This apparently didn't work. At least, I've just had someone else fail to build Qt because ./configure -nomake examples -nomake demos -nomake tests -opensource - confirm-license failed to create a top-level Makefile. People don't read error messages that don't terminate the script and that still leave this message at the end: Qt is now configured for building. Just run 'make'. Once everything is built, you must run 'make install'. Qt will be installed into /usr/local/Qt-5.0.0 If v8 is to remain a submodule of qtbase (I still don't see why), and you want to make ./configure report an error, you'll have to terminate the script when you encounter the error and make sure not to print a message saying 'Just run make'. Especially because the current error message is still output when -no-v8 *is* used. https://bugreports.qt.nokia.com/browse/QTBUG-23206 So the person seeing the error message has to know whether they can ignore it or not. Not useful. Rather than fix the script, it's probably easier to just remove the submodule and fix all the problems associated with it at once. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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, 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
Hi, On 12/12/2011, at 2:15 PM, ext shane.kea...@accenture.com wrote: >> 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 The Qt v8 repo is a clone of the official v8 git repo, so we preserve whatever formatting Google has chosen. Cheers, Aaron > > > 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 ___ 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 December 2011 10:30:31 Rohan McGovern wrote: > 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 . 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. ___ 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 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. Please make it a top level project. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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 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 10/28/11 1:58 PM, "ext Thiago Macieira" wrote: >On Friday, 28 de October de 2011 13:06:50 you wrote: >> On Friday, October 28, 2011 12:58:43 PM ext Thiago Macieira wrote: >> > 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? >> >> Well, you as maintainer of QtCore decide, right? > >No, since it's not part of QtCore. The qtbase.git maintainer (Lars) could >decide that. > >Also, I have not yet understood how the qt5.pro and overall structure >work. I >know how to build in one of my builds, but the other one fails (with the >EXACT >same sources). > >Besides, I have no idea if there are CI or QA rules that need to be >updated. >I'd rather not do it myself. > >Better let someone who has created a module before do it. 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? Cheers, Lars ___ 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 13:06:50 you wrote: > On Friday, October 28, 2011 12:58:43 PM ext Thiago Macieira wrote: > > 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? > > Well, you as maintainer of QtCore decide, right? No, since it's not part of QtCore. The qtbase.git maintainer (Lars) could decide that. Also, I have not yet understood how the qt5.pro and overall structure work. I know how to build in one of my builds, but the other one fails (with the EXACT same sources). Besides, I have no idea if there are CI or QA rules that need to be updated. I'd rather not do it myself. Better let someone who has created a module before do it. -- 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 Friday, October 28, 2011 12:58:43 PM ext Thiago Macieira wrote: > 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? Well, you as maintainer of QtCore decide, right? Simon ___ 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
Re: [Development] V8's location
On Monday, 24 de October de 2011 10.11.00, Simon Hausmann wrote: > > Can we move V8 out of qtbase and into a top-level module? I've done that > > mistake above several times. The fact that V8 is inside qtbase means I > > cannot do a git commit -a, despite the submodule ignore command. > > > > Also, can we move it to Gitorious and enable Gerrit for it? I have a patch > > to make it compile with ICC and I'd rather not have to create a github > > account just for this. > > 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. To put it bluntly: git submodules should not be used in an active repository. > I'm not sure if putting v8 into gerrit helps much, because things like > rebasing are much harder with Gerrit. In a strange sense we want to make it > difficult to modify our fork of V8 :) You can give push-to-branch rights in Gerrit, which allows rebasing. > That said, does your employer allow you to contribute the patch upstream? To Qt, it's in progress and should happen soon. To V8, definitely not for me. If the repository is not moved to Gerrit, which is fine, I'll probably just publish my changes in Gitorious and expect V8's maintainer to merge them on their own. But please move the submodule to qt5.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. -- Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm, Sweden Registration Number: 556189-6027 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
On Monday, October 24, 2011 09:32:00 AM ext Thiago Macieira wrote: > On Sunday, 23 de October de 2011, às 17.07.24, you wrote: > > Samuel Rødal has posted comments on this change. > > > > Change subject: Improve drawing scaled image with raster using SSE2 > > .. > > > > > > Patch Set 2: Do not submit > > > > You accidentally got src/3rdparty/v8 included in your change, could you > > remove it? > > Can we move V8 out of qtbase and into a top-level module? I've done that > mistake above several times. The fact that V8 is inside qtbase means I cannot > do a git commit -a, despite the submodule ignore command. > > Also, can we move it to Gitorious and enable Gerrit for it? I have a patch to > make it compile with ICC and I'd rather not have to create a github account > just for this. Isn't the right solution then to get your patch either upstream or into the Qt copy? I'm not sure if putting v8 into gerrit helps much, because things like rebasing are much harder with Gerrit. In a strange sense we want to make it difficult to modify our fork of V8 :) That said, does your employer allow you to contribute the patch upstream? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
