| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
RevBy: mread
|
|
|
|
|
|
|
|
|
| |
Using just -lQtUiTools instead of -lQtUiTools.lib will make qmake
attempt to autodetect whether or not the lib is static or dynamic,
which will not work since QtUiTools is not necessarily yet built.
Task-number: QT-1018
Reviewed-by: Janne Koskinen
|
|\ |
|
| |
| |
| |
| |
| |
| | |
This is required by the Helix plugin. As discussed with Dallas team/Fu Liz.
Reviewed-by: Shane Kearns
|
|/
|
|
|
|
|
|
| |
Fix for applications not compiling containing #include<QtWebkit>
due to relative inclusion problem in Symbian build environment.
Task-number: QTBUG-4846
Reviewed-by: Iain
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VCPROJ/SLN generator generates dependencies on the glue project,
so the glue must use the correct library for the dependencies to be
correct. The qtAddLibrary() would add the project 'default' to the
glue, which could end up adding a debug lib to the glue, so the
dependency checker wouldn't find the proper project.
We therefore force qtAddLibrary to only add d/_debug if we're not
using debug_and_release, or not in the glue part
Reviewed-by: Rohan McGovern
|
|
|
|
|
|
|
|
|
| |
It was decided on weekly telco that Symbian pkg and sis files can use
plain Qt name, since it is already clear that user is installing
"Qt for Symbian" version of Qt.
Task-number: QT-772
Reviewed-by: Miikka Heikkinen
|
|\ |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Prepending adds epoc32\include too early into generated
systeminclude path search order causing Webcore build
to break due to wrong animation.h header getting included.
Reviewed-by: Jason Barron
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The new public classes in the 's60framework' sub-directory of QtGui
introduce a header file dependency to the middleware layer of the SDK
by including 'aknapp.h'.
Since the build system doesn't know if you have included QtGui or not,
the closest approximation is to append the middleware layer include
path in cases where the QT variable contains 'gui'
Reviewed-by: axis
|
| |/
| |
| |
| |
| |
| |
| |
| | |
Phonon.
Both epoc32/include and $QTDIR/include/Phonon contain a file called videoplayer.h. Both of these directories are listed as SYSTEMINCLUDE paths in the generated MMP file, with the Phonon path coming first. This means that '#include <videoplayer.h>' picks up the Phonon header rather than (as intended) the Symbian one.
A new qmake variable, PREPEND_INCLUDEPATH, is defined, allowing the .pro file to specify that /epoc32/include should be the first SYSTEMINCLUDE.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some changes was done on Mac to support Qt building statically
on Cocoa. Unfortunatly, the change lead to many visibility warnings
because, with the change, src/tools/bootstrap was made with symbols
hidden by default (-fvisibility=hidden). Then, when building the
tools (moc, rcc etc), visibility was public by default (for internal
classes used by Qt). This caused warnings. The change is now temporarily
reverted until Morten get a second chance to look at it.
Rev-By: prasanth
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This introduces an undocumented "phonon_compat" subdir and also adds
it to the INCLUDEPATH when QT += phonon is specified. With this, these
styles of #includes should be supported:
#include <Phonon>
#include <Phonon/Phonon>
#include <phonon>
#include <phonon/phonon>
#include <Phonon/MediaObject>
#include <phonon/mediaobject.h>
Still need to check if the headers get installed during "make
install". I couldn't find where in our code that is done.
BT: yes
Reviewed-By: Trust Me
|
| |
| |
| |
| | |
Reviewed-By: TrustMe
|
| |
| |
| |
| |
| |
| |
| | |
Several script and webkit tests require increased maximum heap
in emulator, so just increase the maximum heap for all autotests.
Reviewed-by: Janne Koskinen
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a workaround for the fact that removing --export_all_vtbl from
the RVCT command line seems to cause problems when linking the static
s60main lib with apps built with GCCE (at least 4.3, haven't tested
earlier versions)
The root cause still needs to be found and fixed, after which this
workaround can hopefully be removed.
Problem observed on Symbian^3 release, RVCT 2.2 build 686,
GCC-E 2009q1-162 release from CodeSourcery.
Reviewed-by: axis
|
| |
| |
| |
| |
| |
| |
| | |
SBSv1 has also been updated to define the appropriate macros and add the
required library statements, so all that is needed is the STDCPP keyword
Reviewed-by: mread
|
| |
| |
| |
| |
| | |
Add -all_load to make Objective-C categories work.
Enable hide_symbols to remove visibility issues.
|
|/
|
|
|
|
|
| |
Skipped addExclusiveBuilds function in debug_and_release.prf for all
Symbian platforms, as it doesn't work with Symbian toolchain.
Reviewed-by: Janne Anttila
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This way we avoid having a lot of code in a static (and
unmaintainable) library. The s60main static library now currently has
only one task: to call main().
To move the initialization into QtGui also meant a change in how the
S60 framework is created, because we can no longer use the trick
where we create and start the the S60 event loop and then have the
framework call us back to start main(). The initialization now
follows the creation and destruction of QApplication, which is a lot
more in line with how other platforms do it.
Since S60 doesn't support creating the environment, and *then*
starting it (both are executed by the same call), we had to open up
the S60 framework construction classes and just mirror what they do.
This means that after QApplication construction is done, the S60
framework is initialized, but nothing will run yet and control will
return to main(), where the user can start the event loop himself.
One of the quirks of this approach is that the construction of the
S60 framework makes a new cleanup stack. This means that any active
traps will not be active anymore, and leaving without setting a new
trap will most likely panic. This shouldn't be a problem for us,
since Qt is never supposed to leave, but it means that if anyone uses
the cleanup stack without setting a new trap, they will receive a
panic.
It was considered to add a trap mark in QApplication construction and
then removing it on destruction, but it was dropped because leaving
from main() is still undefined (even if the old cleanup stack would
be restored in the destructor, we wouldn't be able to stop the
exception from unwinding the stack, and the cleanup stack would then
be unbalanced).
RevBy: Jason Barron
RevBy: Janne Anttila
AutoTest: QWidget passed with same failure count
|
|/
|
|
|
|
|
|
|
| |
The Symbian build system can't handle directories starting with a `.',
so qmake aborts if MOC_DIR and similar start with a `.'. However,
the check for this condition was faulty and would include any path
which contained a `.' anywhere.
Reviewed-by: Michael Goddard
|
|
|
|
|
|
|
|
|
|
| |
This introduces a QAbstractVideoSurface interface for implementing arbitrary
video outputs, and a QVideoFrame type. Also included is the
QVideoSurfaceFormat class which is used to configure the input to a video
surface, and the QAbstractVideoBuffer class which allows QVideoFrames
to be constructed from non-native frame types.
Reviewed-by: Dmytro Poplavskiy
|
|\ |
|
| |
| |
| |
| | |
Reviewed-by: Miikka Heikkinen
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure.exe
examples/examples.pro
qmake/Makefile.unix
qmake/Makefile.win32
qmake/Makefile.win32-g++
qmake/Makefile.win32-g++-sh
qmake/qmake.pro
src/script/api/qscriptable.h
src/script/api/qscriptclasspropertyiterator.h
src/script/api/qscriptcontext.h
src/script/api/qscriptengineagent.cpp
src/script/api/qscriptstring.cpp
src/script/api/qscriptstring.h
src/script/api/qscriptvalueiterator.cpp
src/script/api/qscriptvalueiterator.h
src/script/qscriptclass.cpp
src/script/qscriptcontext.cpp
src/script/qscriptengine.cpp
src/script/qscriptengine_p.cpp
src/script/qscriptvalue.cpp
src/script/qscriptvalue_p.h
src/script/qscriptvalueimplfwd_p.h
src/script/script.pro
src/src.pro
tests/auto/auto.pro
tests/auto/qscriptv8testsuite/tst_qscriptv8testsuite.cpp
tools/configure/configureapp.cpp
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | | |
Reviewed-by: TrustMe
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 4dd03abdfbcc1af3075b30165e19ee63fe8051f4. And changes
stl.prf slightly to get the Qt libs compiled again without reverted hack.
Conflicts:
src/gui/painting/qblackraster.c
|
|\ \ |
|
| |\ \
| | |/
| | |
| | |
| | | |
Conflicts:
tests/auto/auto.pro
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Removed symbian specific functionality from project.cpp:
- generate_test_uid qmake function removed
- Uids are now generated automatically for projects that don't have
one.
- Usage of ICON (in application_icon.prf) now requires explicit
UID3 definition.
- Autotests that require UID3 in .pro now define it explicitly
- Move most symbian specific function implementations away from
project.cpp to files under generators/symbian
Reviewed-by: Janne Anttila
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
doc/src/examples.qdoc
doc/src/plugins-howto.qdoc
doc/src/topics.qdoc
examples/phonon/musicplayer/mainwindow.cpp
src/3rdparty/freetype/src/base/ftobjs.c
src/corelib/global/qglobal.h
src/corelib/tools/qalgorithms.h
src/corelib/tools/qshareddata.cpp
src/corelib/tools/qsharedpointer.cpp
src/corelib/tools/tools.pri
src/corelib/xml/qxmlstream.h
src/gui/painting/painting.pri
src/gui/widgets/qdatetimeedit.cpp
tests/auto/qdesktopservices/qdesktopservices.pro
tests/auto/qgraphicsitem/tst_qgraphicsitem.cpp
tests/auto/qtextcodec/test/test.pro
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On the Mac, it means "-framework ApplicationServices -framework Carbon
-framework AppKit" are no longer part of the default LIBS in Qt
applications. This required a lot of fixes where we used Mac-specific
code in Qt.
On X11, it was very straightforward, because we apparently use very
little of X11 outside QtGui.
I haven't changed the Windows-specific LIBS paths, because I don't
know how Windows behaves. Windows has DLLs, but it links to static
"import" libraries. So is it static linking or dynamic linking?
Reviewed-By: Marius Storm-Olsen
|
| |/
| |
| |
| |
| |
| | |
Commit 7f1cba82 causes {x86, x86_64, ppc, ppc64}.prf to be loaded before objective_c.prf.
This will add content to QMAKE_OBJECTIVE_CFLAGS, causing the isEmpty test to skip
populating QMAKE_OBJECTIVE_CFLAGS. Remove the isEmpty test to fix the issue.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the Qt package contains one of x86 and x86_64, pick that one. If it
contains both then use the compiler default. Make a similiar decision for
PowerPC-based systems. Note that this logic assumes that Qt has been
configured with an architecture that is usable on the system.
Reviewed-by: Marius Storm-Olsen
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
can not be found change that behavior to warn by default.
Currently the default behavior of include() in a .pro file is not to
warn if the supplied file argument can not be found which can lead to
hard to find build errors. The include() will now,by default, warn if
the specified file can not be found.
If a warning is not required because the included file is optional then
example use in the .pro file:
include(SomePriFile.pri", "", true)
Task-number:259398
Reviewed-by:Marius Storm-Olsen
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure.exe
doc/src/classes/qnamespace.qdoc
examples/examples.pro
src/corelib/kernel/qcoreevent.cpp
src/corelib/kernel/qobject.cpp
src/gui/kernel/qapplication.cpp
src/gui/kernel/qstandardgestures.h
src/gui/kernel/qwidget.cpp
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/global/qglobal.h
src/corelib/kernel/qmetatype.cpp
src/corelib/kernel/qobject.cpp
src/corelib/thread/qthread_unix.cpp
src/gui/graphicsview/qgraphicssceneevent.h
src/gui/itemviews/qheaderview.h
src/gui/kernel/qapplication_qws.cpp
src/gui/kernel/qgesture.h
src/gui/kernel/qgesturerecognizer.h
src/gui/painting/qpaintengine_raster.cpp
src/network/access/qhttpnetworkreply.cpp
src/network/access/qnetworkcookie.h
src/network/socket/qnativesocketengine_unix.cpp
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Task: 242139
This commit replaces Symbian specific 'depends' keyword in qmake
DEPLOYMENT variable with two more generic ones. The new keywords
are 'pkg_prerules' and 'pkg_postrules', and they allow developer to
pass raw data to PKG file. The strings in 'pkg_prerules' are added
before PKG file package-body headers and 'pkg_postrules' after them.
Correspondingly as old 'depends' keyword, the new keywords are not
parsed by qmake, so they must be in a format understood by Symbian
package generation tools.
Note that 'pkg_prerules' can also replace default language,
package-header and vendor statements in pkg file. If you decide to
override any of these statements, you need to pay attention that
also other statements stay valid.
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
config.tests/unix/openssl/openssl.pri
demos/embedded/embedded.pro
examples/itemviews/chart/chart.pro
examples/network/network.pro
examples/painting/painterpaths/painterpaths.pro
examples/threads/mandelbrot/mandelbrot.pro
qmake/project.cpp
src/3rdparty/libtiff/libtiff/tif_config.h
src/corelib/arch/arch.pri
src/corelib/global/qglobal.cpp
src/corelib/kernel/kernel.pri
src/corelib/kernel/qcore_unix_p.h
src/corelib/kernel/qobject.cpp
src/corelib/thread/qthread_unix.cpp
src/corelib/tools/qsharedpointer_impl.h
src/corelib/tools/tools.pri
src/gui/kernel/qaction.h
src/gui/kernel/qapplication.cpp
src/gui/painting/qregion.h
src/gui/widgets/qlineedit.cpp
src/gui/widgets/qlineedit_p.h
src/network/socket/qnativesocketengine_unix.cpp
tests/auto/qdir/tst_qdir.cpp
tests/auto/qdiriterator/tst_qdiriterator.cpp
tests/auto/qhttp/qhttp.pro
tests/auto/qline/qline.pro
tests/auto/qnetworkreply/tst_qnetworkreply.cpp
tests/auto/qresourceengine/qresourceengine.pro
tests/auto/qsharedpointer/qsharedpointer.pro
tests/auto/qstring/qstring.pro
tests/auto/qtcpsocket/qtcpsocket.pro
tests/auto/qtcpsocket/tst_qtcpsocket.cpp
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes Qt work on VxWorks 6.6+ in native (kernel) mode.
* compiles with the WindRiver GNU toolchain (Linux only)
* works with QWS (tested with the VNC driver only)
* tested on PPC hardware and the x86 VxWorks simulator
* no q3support, no phonon, no webkit
* no QSharedMemory, no QSystemSemaphore, no QProcess
* only one QApplication instance (flat address space)
* filesystem support depends heavily on the quality of the native driver
* QLibrary is just a dummy to make plugins work at all
* qmake transparently creates VxWorks munching rules for static ctors
* made auto-test cope with missing OS features
A special note regarding the Q_FOREACH patch for dcc:
when calling foreach(a,c) with c being a function returning a container,
the compiler would generate 5 references to some labels (.LXXXX), which
are not there (so the linker complains in the end).
Seems like dcc doesn't really like the 'true ? 0 : <function call to get type>'
statement
Reviewed-By: Harald Fernengel
|
|\ \ \
| |/ /
| | /
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure.exe
qmake/Makefile.unix
qmake/generators/makefile.cpp
src/corelib/global/qglobal.h
src/corelib/kernel/kernel.pri
src/corelib/kernel/qcoreevent.cpp
src/corelib/kernel/qsharedmemory_unix.cpp
src/gui/graphicsview/qgraphicsscene.cpp
src/gui/kernel/qaction.cpp
src/gui/kernel/qaction.h
src/gui/kernel/qaction_p.h
src/gui/kernel/qapplication.cpp
src/gui/kernel/qapplication.h
src/gui/kernel/qwidget.cpp
src/gui/kernel/qwidget.h
src/gui/kernel/qwidget_mac.mm
src/gui/painting/qgraphicssystemfactory.cpp
src/gui/styles/qwindowsstyle.cpp
src/gui/text/qfontengine_qpf.cpp
src/gui/widgets/qabstractscrollarea_p.h
src/network/access/qnetworkaccessdebugpipebackend.cpp
src/network/socket/qlocalsocket_unix.cpp
src/network/socket/qnativesocketengine_p.h
src/network/socket/qnativesocketengine_unix.cpp
src/openvg/qpaintengine_vg.cpp
tests/auto/q3sqlcursor/tst_q3sqlcursor.cpp
tests/auto/qcssparser/qcssparser.pro
tests/auto/qdir/tst_qdir.cpp
tests/auto/qfile/tst_qfile.cpp
tests/auto/qobject/tst_qobject.cpp
tests/auto/qpathclipper/qpathclipper.pro
tests/auto/qprocess/tst_qprocess.cpp
tests/auto/qsettings/tst_qsettings.cpp
tests/auto/qsharedpointer/qsharedpointer.pro
tests/auto/qsqlquerymodel/qsqlquerymodel.pro
tests/auto/qsqlrelationaltablemodel/qsqlrelationaltablemodel.pro
tests/auto/qsqltablemodel/qsqltablemodel.pro
tests/auto/qsqlthread/qsqlthread.pro
tests/auto/qwidget/tst_qwidget.cpp
|