problem trying to package a finished build
I need to change the Font Max Size on a couple of files of the source code of
Xulrunner
and rebuild it for Centos 6 64 bits
Those two lines are
gfxFont.h
#define FONT_MAX_SIZE 2000.0
and at cairo-ft-font.c :
#define MAX_FONT_SIZE 1000
and i change those two values to much larger values.
I tried to rebuild it myself and the build works but then i cant manage to
package it to be able to move it all together to a different folder on my
server and execute it properly, this is what i have done so far
1) First i downloaded the source from here:
hg clone http://hg.mozilla.org/mozilla-central/ src
Then i set the variable $topsrcdir to the folder where i put the source
Then i did cd src and inside src i did:
echo . \$topsrcdir/xulrunner/config/mozconfig .mozconfig
to point the build to the configuration file for Xulrunner
2) Then inside $topsrcdir/xulrunner/config/mozconfig i added
# This file specifies the build flags for XULRunner. # .
ac_add_options --enable-application=xulrunner
ac_add_options --disable-system-cairo
mk_add_options MOZ_OBJDIR=@topsrcdir@/obj-xulrunnerfinished
so i specified the output folder and also i try to disable system cairo so that
build hopefully will pick the cairo with the modified source code of the files
i changed instead of the linux system cairo (as i need to change the font max
size value and i changed that in the source code files so i have to make sure
that the build picks the files of the source code i changed, instead of the
linux system cairo)
3) Then i make the build with
make -f client.mk build
I got errors because my Python and GCC versions were too old,
so i updated Python and GCC to the correct versions and then
the build executed well
4) The build completed and as a result i got an output folder
called obj-xulrunnerfinished (as specified in the mozconfig)
5) I can now successfully run the new xulrunner from the /dist/bin subfolder
like this
[root@ns236697 bin]# pwd
{install folder}obj-xulrunnerfinished/dist/bin
[root@ns236697 bin]# ./xulrunner
Mozilla XULRunner 28.0a1
Usage: xulrunner [OPTIONS]
xulrunner APP-FILE [APP-OPTIONS...]
OPTIONS
--app specify APP-FILE (optional)
-h, --help show this message
-v, --version show version
--gre-version print the GRE version string on stdout
--install-app application [destination [directoryname]]
Install a XUL application.
APP-FILE
Application initialization file.
APP-OPTIONS
Application specific options.
6) The next and final step is to
Package the new xulrunner so that i can move it and put it somewhere else in my
server
So i go to the root of the results and i do:
make package
but it fails with an error in python file related to Symlinks
obj-xulrunnerfinished]# make package
make[1]: Entering directory
`{installed-folder}/obj-xulrunnerfinished/xulrunner/installer'
Makefile:71: FULL_NSPR_CFLAGS=-I\${includedir}
make export
make[2]: Entering directory
`{installed-folder}/obj-xulrunnerfinished/xulrunner/installer'
Makefile:71: FULL_NSPR_CFLAGS=-I\${includedir}
make[2]: Nothing to be done for `export'.
make[2]: Leaving directory
`{installed-folder}/obj-xulrunnerfinished/xulrunner/installer'
make compile
make[2]: Entering directory
`{installed-folder}/obj-xulrunnerfinished/xulrunner/installer'
Makefile:71: FULL_NSPR_CFLAGS=-I\${includedir}
make[2]: Nothing to be done for `compile'.
make[2]: Leaving directory
`{installed-folder}/obj-xulrunnerfinished/xulrunner/installer'
make libs
make[2]: Entering directory
`{installed-folder}/obj-xulrunnerfinished/xulrunner/installer'
Makefile:71: FULL_NSPR_CFLAGS=-I\${includedir}
make make-package-internal
make[3]: Entering directory
`{installed-folder}/obj-xulrunnerfinished/xulrunner/installer'
Makefile:71: FULL_NSPR_CFLAGS=-I\${includedir}
OMNIJAR_NAME=omni.ja \
{installed-folder}/obj-xulrunnerfinished/_virtualenv/bin/python
{installed-folder}/toolkit/mozapps/installer/packager.py -DMOZ_GLUE_IN_PROGRAM
-DNO_NSPR_10_SUPPORT -DDLL_PREFIX=lib -DDLL_SUFFIX=.so -DBIN_SUFFIX=
-DGRE_MILESTONE=28.0a1 -DGRE_BUILDID=20131113193941 -DMOZ_DEB_TIMESTAMP=Wed,
13 Nov 2013 21:34:22 +0100 -DMOZ_APP_NAME=xulrunner
-Dinstalldir=/usr/local/lib/xulrunner-28.0a1 \
--format omni \
\
--ignore-errors \
\
\
--optimizejars \
\
../../dist ../../dist/xulrunner \
Traceback (most recent call last):
File {installed-folder}/toolkit/mozapps/installer/packager.py, line 375, in
module
main()
File {installed-folder}/toolkit/mozapps/installer/packager.py, line 320, in
main
sink.close(args.manifest is not None)
File {installed-folder}/python/mozbuild/mozpack/packager/__init__.py, line
366, in close
self.packager.close()
File {installed-folder}/python/mozbuild/mozpack/packager/__init__.py, line
298, in close
self._queue.execute()
File {installed-folder}/python/mozbuild/mozpack/packager/__init__.py, line
217, in execute
function(*args)
File {installed-folder}/toolkit/mozapps/installer/packager.py, line 219, in
add_manifest
self._formatter.add_manifest(entry)
File
HTML CSS Ruby in Gecko
Hi All: At the W3C TPAC conference in China, there's a lot of activity around HTML CSS Ruby. Here are the relevant spec drafts presented at the conference: HTML: http://darobin.github.io/html-ruby/ CSS: http://www.w3.org/TR/css3-ruby/ The Platform Rendering team is investing a lot of energy in East Asian language text layout with our Writing Modes (Vertical Text) implementation. Based on feedback at the conference, it seems like Ruby layout should be the next Text feature for our readers in this part of the world. At TPAC, we are asked to implement the HTML parser and Content changes required to implement the features, even as the presentational Layout requirements are being specified. As the requested changes extend beyond the scope of Rendering, I'm reaching out to the DOM implementers to weigh in on the spec and the work required. I think this is the HTML parser/DOM bug: https://bugzilla.mozilla.org/show_bug.cgi?id=664104 I believe the Layout to-do items appear as recent comments on these two bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=9 https://bugzilla.mozilla.org/show_bug.cgi?id=256274 Thanks, --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shared Desktop and Metro profile work on mozilla-central
I seem to remember that metro and desktop have a completely different format and implementation of session restore (bug 886336). Has this been somehow fixed? Cheers, David On 11/13/13 3:34 PM, Brian R. Bondy wrote: Over the past few weeks, we've been working on Metro and Desktop shared profiles. You can find some background information about this work on my blog [here][1]. Within the next week, if QA gives us the OK, well, we'll be uplifting the Metro and Desktop shared profile work from the oak branch to mozilla-central. As a side effect of this, if you have data in your Metro profile, it will no longer be accessible. Instead, you'll see your Firefox Desktop profile data inside the Metro environment. This message is just a heads up, if you see anything breaking, please post a new bug, CC :bbondy, and put a dependency on bug 924860. If you can think of any reason why this should not land, please speak up :) I'd like to land it sooner than later so that it has a bit of time to bake on mozilla-central. [1]: http://www.brianbondy.com/blog/id/155/shared-profiles-for-metro-firefox-and-desktop-firefox ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shared Desktop and Metro profile work on mozilla-central
It has a but filed and work planned already in bug bug 886336. I don't think that's a blocker to landing though, and for some reason it seems to magically work, but we definitely need to do bug 886336. On Thursday, November 14, 2013 4:23:09 AM UTC-5, David Rajchenbach-Teller wrote: I seem to remember that metro and desktop have a completely different format and implementation of session restore (bug 886336). Has this been somehow fixed? Cheers, David On 11/13/13 3:34 PM, Brian R. Bondy wrote: Over the past few weeks, we've been working on Metro and Desktop shared profiles. You can find some background information about this work on my blog [here][1]. Within the next week, if QA gives us the OK, well, we'll be uplifting the Metro and Desktop shared profile work from the oak branch to mozilla-central. As a side effect of this, if you have data in your Metro profile, it will no longer be accessible. Instead, you'll see your Firefox Desktop profile data inside the Metro environment. This message is just a heads up, if you see anything breaking, please post a new bug, CC :bbondy, and put a dependency on bug 924860. If you can think of any reason why this should not land, please speak up :) I'd like to land it sooner than later so that it has a bit of time to bake on mozilla-central. [1]: http://www.brianbondy.com/blog/id/155/shared-profiles-for-metro-firefox-and-desktop-firefox ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unified builds
On 11/14/13, 2:49 PM, Ehsan Akhgari wrote: The way that unified builds work is by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build files. With that, the build system creates files such as: // Unified_cpp_path_0.cpp #include Source1.cpp #include Source2.cpp // ... Are the UNIFIED_SOURCES from one moz.build file ever unified with another moz.build file's UNIFIED_SOURCES? I see that UNIFIED_SOURCES only supports .c and .cpp (and .cc) sources. Is there any reason why .mm files are not also supported? Do Objective-C's #imports cause problems? chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unified builds
On 2013-11-14 6:29 PM, Chris Peterson wrote: On 11/14/13, 2:49 PM, Ehsan Akhgari wrote: The way that unified builds work is by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build files. With that, the build system creates files such as: // Unified_cpp_path_0.cpp #include Source1.cpp #include Source2.cpp // ... Are the UNIFIED_SOURCES from one moz.build file ever unified with another moz.build file's UNIFIED_SOURCES? I don't think so, which is good. You don't want to do that since then adding a file in one directory can break the build in another! I see that UNIFIED_SOURCES only supports .c and .cpp (and .cc) sources. Is there any reason why .mm files are not also supported? Do Objective-C's #imports cause problems? Ironically I fixed that before seeing your email! See bug 938844. One piece of interesting data point. I have a whole bunch of patches locally which makes us build all of layout/ in unified mode. With those patches applied, and after touching all of the .cpp files in layout/, I can rebuild that directory in about 4 seconds on my machine. How long this takes without those patches is left as an exercise for the readers' imagination. :-) Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
