For upcoming Meego devices there is a new graphic toolkit called MeegoTouch (see http://meego.gitorious.org/meegotouch/) This library is built on top of Qt so the attached patch adds a new --enable-meegotouch switch which adds the MeegoTouch libraries and include paths to the Qt related variables. The MOZ_ENABLE_MEEGOTOUCH #define can then be used to mark the MeegoTouch specific code.
I'm not a fan of adding new configure options. Is this something that can be detected based on the existing options, like --with-maemo-version ?
In theory it is still possible to build a pure Qt version of xulrunner even if you are on Maemo6/MeeGo. So I think these are two options should really be separate.
I am trying to reduce the number of configure options, because they are an attractive nuisance for people building Mozilla, and they cause headaches when they don't work as expected. If the only reason to ever use this is on Maemo6/MeeGo, then it should just be the default there, and not an option. In theory it's possible to do a lot of things. If we're going to ship our builds with this enabled, it should be on by default.
Yeah, that makes sense (it's not like I did not get tangled up in the various options before :-) ). So would you be ok with a patch that enables it per default on Maemo6/Meego and and still having an option to disable it explicitly?
Comment on attachment 461301 [details] Patch to add --enable-meegotouch switch how about just using MAEMO 6 for now?
Yeah, --with-maemo-version=6 should just turn this on.
Assignee: nobody → steffen.imhof
Ok, I still think that these are not logically connected, but I see the point about keeping things simple. I'll update the patch soon. But it is ok to keep an (extra) MOZ_ENABLE_MEEGOTOUCH to guard the MeegoTouch specific code, right?
Now the configure script enables MeegoTouch whenever the Maemo version is greater than 5.
Sorry, the last version of the patch was missing MOZ_ENABLE_MEEGOTOUCH which is used in dependent patches.
I heard that Jeremias and Doug agreed in a private chat on using MOZ_PLATFORM_MEEGO instead of USE_MEEGOTOUCH, so here it is. (though I still think of MeegoTouch as a toolkit not as a platform)
Attachment #462095 - Flags: review?(ted.mielczarek) → review?(me)
Comment on attachment 462095 [details] [diff] [review] Updated patch with a new name for the #define As long as maemo > 5 requiring meegotouchcore is ok this is fine. r=me
Attachment #462095 - Flags: review?(me) → review+
Summary: Add a build switch to enable MeegoTouch support → Add a build support for MeegoTouch
Comment on attachment 462095 [details] [diff] [review] Updated patch with a new name for the #define >+ AC_DEFINE(MOZ_PLATFORM_MEEGO) MOZ_ENABLE_MEEGOTOUCH?
No, I think he wants MOZ_PLATFORM_MEEGO to mirror MOZ_PLATFORM_MAEMO.
(In reply to comment #13) > No, I think he wants MOZ_PLATFORM_MEEGO to mirror MOZ_PLATFORM_MAEMO. Ah, ok.
Comment on attachment 462095 [details] [diff] [review] Updated patch with a new name for the #define If MOZ_PLATFORM_MEEGO is intentional then that should replace MOZ_ENABLE_MEEGOTOUCH. I don't really care what it's named as long as the makefile define and the c define are consistent.
Attachment #462095 - Flags: review+ → review-
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.