Qt for iOS Preview

Published Tuesday March 5th, 2013 | by

We are very excited to be able to bring Qt to a new platform. Qt for iOS is planned to be a supported part of Qt 5.2, scheduled for release late 2013. The scope of that release is not completely determined: available resources, platform/app store restrictions and Qt legacy set constraints on the project. This blog outlines the current plan.

Qt 5.1 will contain a preview – which was in fact merged last Friday. It’s also possible to take a look today by checking out the Qt source code. See “Getting Started” for detailed instructions below.

Development and Deployment
Development and especially deployment is done using Xcode. The supported workflow is to maintain a .pro file based project, export it to Xcode (and re-export when the project setup changes), and then build and deploy using Xcode. Source code editing can as usual be done in any editor.

Qt 5 Architecture
Understanding the level of support various Qt modules will get, requires a brief detour into Qt 5 architecture. With Qt 5 there is now a common API that all platforms implement (the Qt platform abstraction – QPA). Most of the Qt for iOS project work will happen here, and this is the code base the team will support. The QPA layer powers both widgets and QML (1 and 2).

Styling
The Qt Mac style uses the HITheme API provided by OS X to draw native-looking UI elements. There is no such API on iOS, which means creating a QiOSStyle similar to QMacStyle is not possible. Cross-platform styles such as the new Fusion style will however be available. Future styling efforts will focus on controls for Qt Quick 2.

Qt Quick 2: JavaScript engines and JIT
Qt Quick 2 uses the V8 javascript engine, which cannot be deployed on iOS due to policy and technical limitations related to V8′s use of a just-in-time compiler. This means no Qt Quick 2 on iOS for the time being. We are aware of the problem and are working on a solution.

What works today

  • Widgets
  • Graphics View
  • Qt Quick 1
  • OpenGL
  • Touch events
  • Orientation events
  • ++

Qt5 Cinematic Experience by QUIt Coding, ported to Qt Quick 1 and running on an iPad

 

Getting started

  1. Homework: Setup Xcode for development (acquire certificates, configure devices). Test-deploy one of the standard Xcode app templates. Make sure you have Git installed.
  2. Clone qtbase
    git clone git://gitorious.org/qt/qtbase.git qtbase-ios
    cd qtbase-ios/
    git checkout dev

    [Optional: git checkout ios for the development branch]
  3. Build QtBase for either device or simulator. Note that unlike Qt 4, Qt 5 does not support multi-architecture builds.
    /configure -xplatform unsupported/macx-ios-clang -developer-build -nomake examples -nomake tests -release [-sdk iphonesimulator]
    make
  4. Get the Simple Demo:
    git clone git://github.com/msorvig/qt-ios-demo.git
    cd qt-ios-demo
    ../qtbase-ios/bin/qmake
    open qt-ios-demo.xcodeproj

Update: Building Qt Quick 1
You need the full Qt source code, see Building Qt 5 from Git. Then build the QtScript and QtQuick1 modules:

cd qtscript; ../qtbase/bin/qmake; make; cd ..
cd qtquick1; ../qtbase/bin/qmake; make; cd ..

Did you like this? Share it:
Bookmark and Share

Posted in Uncategorized

101 comments to Qt for iOS Preview

Sonu Lohani says:

Great sir,
You’ve done a very great work. I appreciate you for putting all your effort in bringing out such a great tools. But i am bothered only for the qt with android. I am waiting for it. Could you please tell me the exact date of this?

Morten Johan Sørvig says:

I’m sure the Qt for Android team will make an announcement when they are ready.

Sonu Lohani says:

Thanks for you’re reply. Open Source Rocks.

Christoph says:

I just did a “git pull” on the qtbase/dev branch, and Android port appeared :)

Eskil Abrahamsen Blomfeldt says:

Qt 5.1 will also contain a preview of the Android port. We merged the QtBase part of the Android port into Qt this morning, like Christoph says. Other modules are still pending. At some point once it is all in, we’ll write a blog about it with some instructions on how to try it out :)

Sonu Lohani says:

Thanks. I’m waiting for this port.

kedadi says:

Apple forbids using a 3rd party JavaScript interpreter for content downloaded dynamically over the Internet. If JavaScript is part of the app, you can safely use V8 to run it.

iOS forbids to execute writable memory. V8 can only do Just-In-Time. So it is technically impossible to run V8 on iOS.

krack says:

What with QtCreator ? Is iOS another build system added to qmake or should I use Xcode IDE ? Can I start a debugging session from within QtCreator ?

Will Stokes says:

Looking good! Any chance you guys will enhance QtCreator (which I’ve grown to really love and switched from XCode years ago) to be able to compile and deploy or even run within the iOS simulator similar to what is done by monotouch?

http://xamarin.com/monotouch

This would avoid having to export to XCode every time your .pro file changes, making the development cycle much easier. That and we could all avoid using the XCode UI entirely. :-)

fonzi337 says:

I second Will’s question. Qt Creator is the best C++ IDE I have come across and would love to be able to stay in the Qt Creator environment. :)

In addition, since XCode does not support QML, I imagine the workflow may be less than ideal if one has to switch back and forth between XCode and Qt Creator. Keeping everything in Qt Creator would be great.

Maurice Kalinowski says:

Hi fonzi and Will,

we are currently investigating our options. Point is, compared to other platforms lots of items are not exported from xCode via command line tools or libraries. Hence we cannot use “default setup”.

Having said that, we are looking into libimobiledevice (http://www.libimobiledevice.org/ ) to check if that would fit our needs to provide a stable development environment with Qt Creator. But as I said, research still ongoing.

Danny says:

What features do you need in XCode that cannot be done on the command line (or via Creator running a custom target)?

While it did take me a while to figure it all out, everything you need to do get a Qt app into the Mac or iOS AppStore can be done on the command line.

Deployment, code-signing, archiving etc can all be done without ever touching XCode. And the iOS simulator is a separate application also.

Will Stokes says:

Another quick question: how large will a Qt app on iOS tend to be? In other words, if all one wanted to do was use QtCore, QtGui and QWidget::paintEvent?

Morten Johan Sørvig says:

Here’s an overview of the current “hello world” cost of the libs in question:

libQt5Core.a 7.0M
libQt5Gui.a 4.6M
libQt5Widgets.a 7.3M
Total: 18.9M

Compressed download size:

libQt5Core.a .gz 3.1M
libQt5Gui.a.gz 2.0M
libQt5Widgets.a.gz 3.1M
Total: 8.2M

Jeff says:

Great work guys! I hope you really do have everything done by the end of the year, can’t wait!
(we need a way to subscribe to these blog posts, so that we’re emailed about new comments)

Matti says:

Thumbs up for this work guys. I’d really wanna see Qt take this sort of last giant leap onto iOS one day :p

Albert says:

Qt is getting better release after release, congratulations guys!

Daniel says:

Qt for Android – Necessitas needs Ministro to run. Qt for iOS choosed similar approach?

Morten Johan Sørvig says:

No, on iOS each application carries its own copy of Qt. Installing Qt to a shared location is not possible due to sandboxing restrictions.

Daniel says:

I prefer this aproach instead of Ministro-style, but does it mean that my finall app will be “huge”? how much MB are Qt libraries?

Morten Johan Sørvig says:

See answer above, Core+Gui+Widgets is around 8 MB compressed.

Daniel says:

Thanks, 8MB is ok

Bill says:

your build instruction isn’t correct,

there is no unsupported/macx-ios-clang, the right one is unsupported/macx-iosdevice-clang

Bill says:

also, for ios6, mac os x 10.8,
we need to change QMAKE_IOS_TARGET_ARCH = armv7

Morten Johan Sørvig says:

Hi! I apologize for the confusion, you want to checkout the “dev” branch. The “macx-iosdevice-clang” mkspec was contributed by Mediator Software for use with that port.

I’ve updated the build instructions to reflect this.

hahaha says:

actually, it doesn’t build with armv7 arch.

Apple dropped armv6 support from recent sdk.

I’m getting this when building Qt with armv7:

Undefined symbols for architecture armv7:
“___clear_cache”, referenced from:
__pcre16_jit_compile in pcre16_jit_compile.o
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [../../lib/QtCore.framework/QtCore] Error 1
make[1]: *** [sub-corelib-make_first] Error 2
make: *** [sub-src-make_first] Error 2

Dude says:

You don’t need to wait for everything perpect, and then release it. Actually, Cinematic Experience is just a good example to show what we can do with Qt5 now. I think it is very enough already for games or UIs. So what we need is some UI components(Qt Cross-platform style) and backend APIs(DB,Multimedia,sensors,etc.). You don’t need to worry about javascript engine, because most developers in iOS are more likely to use C-like languages. Javascript is just an alternative or option.

So just release it ASAP, the community will polish it when they find it is useful.

Morten Johan Sørvig says:

Sounds like a good plan to me – we will release what we have with 5.1 and “polish” type changes are welcome. Javascript is important to us because Qt Quick is important to us.

terry says:

As long as C++ could be the backend of QML, it would be fair enough for many developers.
Javascript could simplify some simple apps development, but we could use c++ to do that too
if we don’t have a decent javascript engine yet.

Andrea Bernabei says:

except that you can’t use most of QtQuick without using JS…there are no public C++ classes for QtQuick elements…and this makes developing UIs a lot slower

Congratulations on the iOS preview!

If you want to use Qt for iOS today, you can also checkout V-Play at http://v-play.net, which is a cross-platform game engine supporting iOS, Android, MeeGo, Symbian and the desktops. We added many components for iOS (Video, Audio, sensors, physics, GameCenter & Facebook plugins, etc.) that simplify working with Qt on iOS.

We have published 2 games in the App stores both running with 60fps (see the showcase section on our website, the source code is also publicly available as part of the SDK). Once Qt5 is ready for iOS and has a decent performance, we are looking forward to exchange our custom renderer with QtQuick2.

Cheers, Chris

Artem Marchenko says:

Looks like a good start!

If Qt 5.1 will support at least QtQuick 1.0, I would go try porting some old apps to iOS just to see how App Store reacts.
I have little doubts about the Qt team technical abilities, but Apple policies..

Are you guys working with Apple on making sure what you do happens to be fine with them or are you more in a mode “we hope Apple doesn’t mind it”?

Morten Johan Sørvig says:

We aim to be in compliance with the app store policies, and there has been Qt applications on the app stores already. I don’t think this will be a problem.

Kari says:

Looks like Qt for iOS uses static linking. Since Qt is LGPL, it would mean that any app submitted to the AppStore needs to be LGPL and release the source code.

There has been some talk about it on this page: http://qt-project.org/wiki/Licensing-talk-about-mobile-platforms.

It also discusses solutions:

With Qt5 the JavaScript engine for QML will change to use V8 which is not LGPL but BSD. This could help the current situation with iOS and static linking if the rest of Qt had some exemption for iOS (and other OS’es where dynamic linking was disabled).

Do you plan to have some exemption for iOS to allow static linking? Updated information about licensing would be great!

Robin Lobel says:

The main purpose of the LGPL is that anyone can use the library used in your program, without you having to disclose the source code of your program. The point concerning static library is to allow anyone to use the same library too.
So IMHO if Qt library is statically linked it doesn’t break this purpose since anyone can use the Qt library anyway by downloading the Qt SDK from Digia.

Tuukka Turunen says:

@Kari: Yes, we are aware of this and thinking what is the best way to solve it. Naturally those holding a commercial license are fine with statically link already now (except for Qt Quick 1). Due to the way Apple has set up their AppStore policies use of Qt (or any other components) with LGPL license is difficult – one very easily gets into the gray zone of LGPL v. 2.1. We do want to make Qt on iOS very successful and easily available, so for sure we will come back to this.

Morten Johan Sørvig says:

Licensing questions are not my area, but as far as I know adding an LGPL exception is not under consideration. What will definitively work is pure open source applications and commercial applications using a Qt license from Digia. LGPL is then up for discussion/interpretation.

Dave Thorup says:

An LGPL exception really should be under consideration. There is already the “Nokia Qt LGPL Exception version 1.0″ which appears to cover code contained within header files (numerical parameters, data structure layouts, accessors, macros, inline functions and templates).

An exception that specifically permits static linking would go a long way to increasing Qt adoption. IMHO it is in line with the spirit of the LGPL license – any source changes to Qt would still need to be made available. The LGPL is designed specifically so that developers can use a library without having to release the source for their own application code. Many people already believe that static linking is permitted by the LGPL (I’m one of them), but it would be immensely beneficial for you, the governing body, to give a concrete statement on the matter.

Qt commercial licenses, while available, are extremely expensive in comparison to the $99 Apple charges for its developer program. Please consider a static library exception for the benefit and growth of the Qt community.

M.S. Babaei says:

tnx for the link :) it helped me made up my mind.

[...] в выпуске Qt 5.1 поддержке платформы Android, компания Digia начала тестирование предварительной реализации Qt для мобильной платформы [...]

Julien Wintz says:

Both dev and ios branches of qtbase build and run fine for both device and simulator configurations. Nice!

However the post claims that both gestures (that I can’t get to work) and Qt Quick 1.0 are working so far. It may be useful to update the post to include qtdeclarative repository build instructions.

Can’t wait to test.

Morten Johan Sørvig says:

You are correct that gestures do not work. But the blog only claims that touch events work :)

Julien Wintz says:

My bad. Touch events work as expected, indeed. Any hints whether Qt 5.1 will handle gestures ?

As for qtdeclarative, I’ve tested the dev branch using the qtbase qmake binary for both device and simulator configurations. Unsurprisingly its fails with Project ERROR: Unknown module(s) in QT_PRIVATE: v8. I guess I’m using the wrong repository, as this one implements Qt Quick 2.0 ;-)

Is there a qtdeclarative repository for Qt Quick 1.0 we can test ?

Morten Johan Sørvig says:

Updated the blog with build instructions for Qt Quick 1.

Gesture support is a bit uncertain. I don’t think I can make any promises for 5.1.

Julien Wintz says:

Great! Many thanks.

xuxiang says:

Is QMediaPlayer supported ? My application can run with Ministro but can’t play sound / songs. I’ve been waiting 2 years for this on Necessitas!

Morten Johan Sørvig says:

Not on iOS at this point :) QtMultimedia has a “Android multimedia plug-in.” commit that looks promising.

Federico says:

Any plan to support Qt3D on iOS at some point..?

Danny says:

“The supported workflow is to maintain a .pro file based project, export it to Xcode (and re-export when the project setup changes)”

So if you make any change to the project, you have throw away the XCode project and re-generate it?! That’s what we had to do with Qt before Creator came along and I don’t miss that ‘workflow’ one bit. The .pro file cannot possibly contain everything and custom build steps (code signing, stripping etc), configurations and targets don’t import so the XCode project has to be setup again every time. And forget about SUBDIRS or any kind of ‘solution’ type projects.

If you’ve ever worked on a Qt project in VisualStudio via the add-in and then had to port that project to the Mac, you’ll know my pain.

Why can’t this be done in Creator? I find it ironic that QML/QtQuick, intended for rapid development of fluid interfaces, requires such frustrating cludges.

Tor Arne Vestbø says:

Creator support is being looked into. For now, Xcode is the way to go for the TP. We are well aware of the limitations.

I’m not sure if the full support of QtCreator is possible. Besides I’m not sure if it’s the best idea. Anyone who develops for iOS knows, that many great features of iOS development are possible only with Xcode – instruments, installing on device. Also it would be really great to be able to mix Qt/QML code with objective-C controllers. In theory it should be possible. This could give the iOS port an enormous power. So I really recommend to keep the option of generating Xcode project file (perhaps in more optimized way), even as an alternative to QtCreator.

Danny says:

I would agree if Qt’s integration with XCode was as good as it is with VisualStudio but it’s not.

Generating your entire XCode project over and over again gets old quickly.

Also Instruments, the device simulator and other tools can be used outside of XCode. They’ve just hidden them in the bundle.

Adam Tenderholt says:

Very nice!! Out of curiosity, how is the iOS Master/Detail Split View Controller handled? Is there a Qt widget that should be used for that?

“The Qt Mac style uses the HITheme API provided by OS X to draw native-looking UI elements. There is no such API on iOS, which means creating a QiOSStyle similar to QMacStyle is not possible.”

Why can’t we just use [UIView drawInRect:]? Qt 5 uses a similar approach with NSScroller in order to draw the new Mountain Lion scrollbars. Without the ability to draw native controls, developing user interfaces in Qt becomes useless except for games with totally custom UI.

Jens says:

It is not as bad as you make it out to be actually. By shipping Qt with some fixed pixmaps we would allow you do to test and polish the IOS and Android apps from any Windows or Linux setup and not lock you to an IOS emulator environment.

The native look and feels matter less in the mobile world because each app is in its own full screen context. There is also a lot of visual variety on those platforms already. In general it might be a good thing if Qt instead ships with a beautiful set of controls that work on both Android and IOS. People don’t necessarily care if things don’t look exactly the same as Apple as long as they have the same level of quality and refinement.

To get an idea of what I mean, take a look at any of these UI kits:
Fresh
UI Kit
Dark UI
These were randomly picked from dribbble.com, but they could all be used in a modern IOS app and few people would complain that they don’t look right there.

People do care if things don’t look exactly the same as Apple – that is a big part of that whole quality and refinement. It’s especially important on Apple platforms for things to be pixel perfect and many Mac users will argue over the smallest details. As an example, those styles you linked simply don’t look right on iOS. They may be nice but if they don’t fit with the platform; they look very out of place. Native controls might be less important on mobile but they are still very important.

We might not have HITheme but we have UIView which will work just as well. It’s important that we leverage it in order to give iOS the same level of Qt quality as any other OS. If Android has a QStyle, iOS should be no different.

LeoS says:

I’m curious what your current thoughts are on how to address the V8 problem. You say you are working on a solution, what are some feasible options? So far I’ve only heard it is impossible to support, but is there some hope?

7 says:

At this point it looks like it will be replaced by another JS engine.

syszux says:

To use this feature, we must have a mac?

7 says:

Technically, you must have MacOS with xcode. I’ve heard it can also work on a PC, also in a VM.

Vincent says:

address the V8 problem by v4vm? Can anyone introduce v4vm?

Richard says:

@Tenderholt: We will not write any QWidgets targeted for iOS, but the UI team will look into which QML controls to enable for mobile applications in general, once they focus on that. Controls similar to UISplitViewController would make sense.
@Petroules: We will probably investigate if we can close the gap a bit by doing something along the lines you describe. But this is not decided yet. We also prioritise to make it easy to enhance native iOS applications with Qt/QML for those that e.g want to embed a QML view inside an otherwise 100% native looking application.

Richard says:

@hahaha: pcre compile issues are about to be fixed, https://codereview.qt-project.org/#change,50028

RP says:

Excellent! I want to ask a more general question if you don’t mind – Can we use pure C++ all the way? How capable will Qt for iOS be? For example, if I were to build a Photography app, which will need to control the camera, take picture, apply image filters, add text, upload to social networks, etc. Can I do it with Qt for iOS now?

Thank you!

Qt4iOS says:

Qt has been on iOS for 1.5 years already! Anyone wanting to use Qt on iOS today, can check out the (3rd party) Qt4iOS SDK at http://www.mediator-software.com . It already supports Qt3D, QtMultimedia, accelerometer & GPS on Qt 4.8, and the Qt4iOS Qt5.0 SDK is currently in testing.

Richard says:

@RP: You can use c++ all the way if you want to. Qt Network works. How to control the camera is not in the pipeline yet.

RP says:

Thanks, Richard. “NOT in the pipeline yet” means it will be supported later, is that right?

Robert says:

Maybe look how Marmalade SDK did it. They don’t need xcode do develop an app.

Fabio says:

Wow…they claim support for all but not for for GNU/Linux.
And 30 day evaluation for the “community edition”…
Still interesting to see how they deal with xcode toolchain.

Philip says:

This is an interesting V8 bug report:
https://code.google.com/p/v8/issues/detail?id=1312

At the bottom, it looks like someone has made a virtual machine for the V8. Enabling V8 to run on iOS without jail-breaking it. Perhaps, QQuick 2.0 won’t have to port to another javascript engine after all?

jiaer says:

to resolve the v8 running on ios this question,you can use the way of unity3d which load pre-build dll.
the js engine has been integrated into exe file.

qtnext says:

ont qt4ios (https://twitter.com/Qt4iOS) I just saw that it’s Qt5 port is now working on qt quick 2 ios without jailbraik. I suppose he has not rewrite a new V8 engine in one day ? is there is no trick to quickly enable Quick2 on ios (apple store ready) ?

Qt4iOS says:

@qtnext It uses iOS security exploits to work, so isn’t really a long term solution (as Apple could close those holes at any time). While it’s possible to hide the methods from Apple, but it’s not really something that would be advisable in an Open Source solution…

One thing that has been learned from the exercise of getting V8 to run on a non-JB device, is that Apple will *NEVER EVER* allow a JIT compiler on iOS. The only way it will get into the App Store is by hiding its existence from Apple…

In any case, the demo SDK for Qt4iOS on Qt 5.0, which will hopefully be released in the next week or so, will allow developers to test their QML2 apps on non-Jailbroken iOS devices. Being able to deploy them to the App Store may have to wait until a non-JIT solution is found for QML2 on iOS…

q8phantom says:

Why don’t you merge your efforts with Qt Digia, isn’t this going to help speed further the development? Why are you working alone in this project? Don’t we have duplicate of efforts going in there and there?

Your efforts are great and it is best to combine with with What Qt is already doing, otherwise we will have a duplicated work.

Qt4iOS says:

The Qt4iOS platform plugin is not open source, and can’t be for legal reasons. All other portions of the work have been contributed to Nokia/Digia/Qt Project (since Qt 4.7 when this work started).

Nicola says:

has someone configured for simulator6.1? I have “don’t found a target”

Lucio says:

I’m facing the following build error:

In file included from kernel/qwindowsysteminterface.cpp:42:
In file included from ../../include/QtGui/5.1.0/QtGui/qpa/qplatformwindow.h:1:
In file included from ../../include/QtGui/5.1.0/QtGui/qpa/../../../../../src/gui/kernel/qplatformwindow.h:59:
In file included from ../../include/QtGui/5.1.0/QtGui/qpa/qplatformopenglcontext.h:1:
In file included from ../../include/QtGui/5.1.0/QtGui/qpa/../../../../../src/gui/kernel/qplatformopenglcontext.h:59:
In file included from ../../include/QtGui/qopengl.h:1:
In file included from ../../include/QtGui/../../src/gui/opengl/qopengl.h:64:
In file included from ../../include/QtGui/qopengles2ext.h:1:
../../include/QtGui/../../src/gui/opengl/qopengles2ext.h:402:9: error: unknown type name ‘khronos_int64_t’
typedef khronos_int64_t GLint64;
^
../../include/QtGui/../../src/gui/opengl/qopengles2ext.h:403:9: error: unknown type name ‘khronos_uint64_t’
typedef khronos_uint64_t GLuint64;
^
2 errors generated.

This is my configure command:
./configure -xplatform unsupported/macx-ios-clang -developer-build -nomake examples -nomake tests -release

Anyone can help?

Tor Arne Vestbø says:

Fixed in c9eb0f9b49e825500f3aace1b84e3e4b143cb98d, pull dev

By the way, for anyone who might be reading this, QiOSStyle being “impossible” to implement is incorrect. You can find the discussion on the mailing list. I am currently working on it but it may be a while before it’s ready.

Arnab says:

This is the error I’m getting on my mac:

————————————————————————————————————————————————————————————

opengl/qopengldebug.cpp:591:24: error: expected ‘)’
typedef void (APIENTRY *GLDEBUGPROC)(GLenum source,GLenum type,GLuint id,GLenum severity,GLsizei length,const GLchar *message,GLvoid *userParam);
^
opengl/qopengldebug.cpp:591:14: note: to match this ‘(‘
typedef void (APIENTRY *GLDEBUGPROC)(GLenum source,GLenum type,GLuint id,GLenum severity,GLsizei length,const GLchar *message,GLvoid *userParam);
^
opengl/qopengldebug.cpp:1089:63: error: unknown type name ‘GLDEBUGPROC’
typedef void (QOPENGLF_APIENTRYP qt_glDebugMessageCallback_t)(GLDEBUGPROC callback, const void *userParam);
^
opengl/qopengldebug.cpp:1118:5: error: unknown type name ‘GLDEBUGPROC’
GLDEBUGPROC oldDebugCallbackFunction;
^
opengl/qopengldebug.cpp:1436:31: error: cannot initialize a parameter of type ‘int’ with an rvalue of type ‘void (*)(GLenum, GLenum, GLuint, GLenum, GLsizei, const GLchar *, GLvoid *)’
d->glDebugMessageCallback(&qt_opengl_debug_callback, d);
^~~~~~~~~~~~~~~~~~~~~~~~~
4 errors generated.
make[2]: *** [.obj/release-static/qopengldebug.o] Error 1
make[1]: *** [sub-gui-make_first] Error 2
make: *** [sub-src-make_first] Error 2
1x-193-157-244-10:qtbase-ios arnab$

Tor Arne Vestbø says:

https://codereview.qt-project.org/#change,51225

Ananth Jasty says:

WFM, doing “git fetch https://codereview.qt-project.org/p/qt/qtbase refs/changes/25/51225/1 && git checkout FETCH_HEAD” should fix the issue, thanks.

howard says:

how to config the QMAKE_IOS_TARGET_ARCH in .pro file,ths:)

tom says:

to get QML1 to work under ios:
once i get and make
cd qtscript; ../qtbase/bin/qmake; make; cd ..
cd qtquick1; ../qtbase/bin/qmake; make; cd .

how do i merge the result of those 2 makes with the qtbase-ios ?
do i just copy the libraries ? if so where to in qtbase-ios ?

Morten Johan Sørvig says:

qmake should place the libraries in the correct location (qtbase-ios/lib). Try it!

tom says:

ah, i see so qtbase-ios should live under qt5

~/qt5/qtbase-ios
/qtscript
/qtquick1

because the QML1 script instructions where after the qtbase-ios i had

~/qt5/
/qtscript
/qtquick1
~/qtbase-ios

tom says:

i tried it and can’t seem to be able to get it to work.

can you show the directory structure of the qt5 and qtcore-ios location ?
if you call qmake from ../qtbase/bin/qmake doesn’t it copy the result into ../qtbase/lib/ instead of qtbase-ios/lib ?

Morten Johan Sørvig says:

The standard setup is:

~/qt5/qtbase
~/qt5/qtscript
~/qt5/qtquick1

With libs under ~/qt5/qtbase/lib

I recommend reading Building Qt 5 from Git and then getting a standard desktop build up and running first.

tom says:

i understand and i followed the instructions before, it’s just that i can’t seem to see how

git clone git://gitorious.org/qt/qt5.git qt5
and
git clone git://gitorious.org/qt/qtbase.git qtbase-ios

fit together

once i build qtbase-ios i can run the 2 ios examples, which makes a xproject which i can run using xcode.
i am just trying to figure out what i need to do to also get QML1 working so it will generate an xcode project.
qt5 and qtbase-ios seem 2 separate qt installs.

or do i just put qtbase-ios in the qt5 directory, replacing qtbase ?

tom says:

and just a check to make sure i understood correctly:

QML1 might be able to get through the app store approval process
QML2 certainly won’t be approved through the app store

?

Morten Johan Sørvig says:

QML1 should get through the approval process. V8 certainly won’t. We are working on making QML2 acceptable for the app store.

tom says:

thank you for clearing that up. much appreciated !
whats the plan on getting it approved ? even another javascript engine needs to do JIT compiling doesn’t it ?

Morten Johan Sørvig says:

No comment :)

tom says:

hehe, i’m sure it would be apple-legal though :)

Jakub Flaska says:

Great! I am also waiting for this release.

Please, does the current version supports QImage & QPainter?

trusktr says:

After cloning then running git checkout dev, it says “Switched to a new branch ‘dev’”. Is that OK? I thought dev already existed. Why does it say it’s a new branch? I think it’s fine though, because git log shows “Bump Qt version to 5.2.0″.

trusktr says:

After doing

cd qtscript; ../qtbase/bin/qmake; make; cd ..
cd qtquick1; ../qtbase/bin/qmake; make; cd ..

What then? How do you get a QtQuick1 app started for iOS? A list of setup steps for Qt Creator and/or command line would be nice. I’m a newb. :D

trusktr says:

Tom attempts (the above comments) to get Qt Quick 1 working weren’t resolved.

After compiling qtscript, I see libQt5Script.a in qt5/qtbase/lib, but after compiling qtquick1 I don’t see libQt5Quick1.a or anything similar in qtbase/lib. Should I see something there if it worked?

trusktr says:

And when I try to qmake my Qt Quick 1 project it says “Project ERROR: Unknown module(s) in QT: quick1″. Any hints on how to get it working?

Commenting closed.