зеркало из https://github.com/mozilla/gecko-dev.git
209 строки
6.9 KiB
Plaintext
209 строки
6.9 KiB
Plaintext
This is the ANGLE project, from http://code.google.com/p/angleproject/
|
|
|
|
Current revision: f3fc6571dca9832876e09c63b0958d413737757b
|
|
Date of revision: 2013-08-02
|
|
|
|
== Applied local patches ==
|
|
In this order:
|
|
angle-build-stdcall-alias.patch:
|
|
Fix an issue GCC has with linking to undecorated stdcalls.
|
|
|
|
angle-build-dedupe-debug-cpp-h.patch:
|
|
Rename: "src/compiler/debug.{cpp,h}"
|
|
To: "src/compiler/compiler_debug.{cpp,h}"
|
|
Repair includes accordingly.
|
|
|
|
angle-build-d3dcompiler-list.patch:
|
|
Move `ANGLE_PRELOADED_D3DCOMPILER_MODULE_NAMES` define from make files to
|
|
Renderer.cpp, where it's used.
|
|
|
|
angle-build-khrplatform-h-path.patch:
|
|
Fix include path for khrplatform.h.
|
|
|
|
angle-build-case-sensitive.patch
|
|
Fixes cross compilation on case sensitive OSes.
|
|
|
|
angle-build-dedupe-uniform-cpp-h.patch:
|
|
Rename: "src/compiler/Uniform.{cpp,h}"
|
|
To: "src/compiler/CompilerUniform.{cpp,h}"
|
|
Repair includes accordingly.
|
|
|
|
angle-build-ttype.patch:
|
|
Remove bit-field markings for TType, since GCC4.7 emits a default
|
|
copy constructor which fails to compile.
|
|
|
|
angle-long-ident-hash.patch:
|
|
Use MurmurHash3 for long identifier hashing. See bug 676071, where we used
|
|
Spooky Hash, before ANGLE came with MurmurHash3.
|
|
|
|
angle-faceforward-emu.patch:
|
|
Adds emulation for faceforward(float,float,float), which is needed to
|
|
prevent crashing on Mac+Intel. See bug 771406.
|
|
|
|
angle-default-clamp-strat.patch:
|
|
Fixes TCompiler::Init to treat `resources.ArrayIndexClampingStrategy`
|
|
as a request for the default strategy.
|
|
|
|
angle-tex-pool-default.patch:
|
|
Don't use D3DPOOL_MANAGED on D3D9. Just use D3DPOOL_DEFAULT.
|
|
|
|
angle-build-unified.patch:
|
|
Fixes required to make angle compile in unified mode
|
|
Note that a different version of this patch was upstreamed, so the next time that
|
|
Angle is updated this patch can be discarded. See:
|
|
https://chromium.googlesource.com/angle/angle/+/0dd3b3ff66cdc50882125d21e60112d5161279b4
|
|
https://chromium.googlesource.com/angle/angle/+/0685fbde65a3e90d8d4d4a6c72f2cc1771617fd0
|
|
|
|
In addition to these patches, the Makefile.in and moz.build build files are ours,
|
|
they're not present in upsteam ANGLE. Therefore, changes made to the build files
|
|
should not be stored in the local .patch files.
|
|
|
|
|
|
== How to do a clean-slate upgrade ==
|
|
1. Backup our moz-specific files:
|
|
README.mozilla
|
|
Makefile.in
|
|
moz.build
|
|
*.patch
|
|
src/libEGL/Makefile.in
|
|
src/libEGL/moz.build
|
|
src/libGLESv2/Makefile.in
|
|
src/libGLESv2/moz.build
|
|
|
|
2. $ rm -rf gfx/angle
|
|
|
|
3. Copy the folder containing the angle rev you want onto gfx/angle.
|
|
$ svn export -r <rev> <src> <moz-central>/gfx/angle
|
|
Or:
|
|
$ git checkout-index --prefix <moz-central>/gfx/angle/ -a
|
|
|
|
4. Fold our moz-specific files into this new angle folder. (Makefiles, README)
|
|
4a. Remove the unused files. (test/, samples/, msvc files)
|
|
|
|
5. Clear out the "Applied Local Patches" section above, since we're going to
|
|
repopulate it.
|
|
|
|
6. Re-apply the angle-build-*.patch files and record them above.
|
|
|
|
7. Update the Makefile.in files with the current deps from the .gyp(i) files.
|
|
|
|
8. Build. Fix things until it builds.
|
|
|
|
9. Reapply the rest of the .patch files and record them above.
|
|
|
|
10. Try runs and reviews!
|
|
|
|
|
|
== Applying Diffs ==
|
|
In general:
|
|
$ patch -p1 -R < gfx/angle/angle-some-bug-fix.patch
|
|
|
|
SVN diffs however can be iffy. They don't seem to be completely compatible
|
|
with `patch`. Be aware that you'll likely get rejects whenever a file is
|
|
removed.
|
|
|
|
|
|
|
|
== How to do an incremental update ==
|
|
Same general idea here, but instead of nuking the ANGLE dir, we're going to
|
|
have to get a diff between revs from SVN, and deal with applying that. We
|
|
also naturally have to peel off our local patches before we can apply a diff
|
|
from upstream.
|
|
|
|
1. Unapply patches
|
|
|
|
Unapply them in reverse order, so iterate over the above list of applied patch
|
|
starting from the bottom. You most likely want to record these patch-unapply
|
|
operations as individual patches themselves, in order to re-apply patches later.
|
|
|
|
$ cd /path/to/mozilla-central
|
|
|
|
$ patch -p1 -R < gfx/angle/angle-some-bug-fix.patch
|
|
$ hg qnew unapply-angle-some-bug-fix.patch
|
|
|
|
2. Apply diff with new ANGLE version
|
|
|
|
Check at the top of this file what ANGLE revision we currently have. Let's say it's
|
|
r123. Check at the ANGLE Web site what recent revisions look like to figure what
|
|
revision seems safe. Let's say we want r456.
|
|
|
|
$ cd
|
|
$ svn checkout http://angleproject.googlecode.com/svn/trunk/ angleproject
|
|
$ cd angleproject
|
|
$ svn diff -r 123:456 > ~/angle-diff-from-123-to-456
|
|
$ cd /path/to/mozilla-central
|
|
$ cd gfx/angle
|
|
$ patch -p0 < ~/angle-diff-from-123-to-456
|
|
$ cd ../..
|
|
$ hg status
|
|
# hg add any new ANGLE files under gfx/angle
|
|
$ hg qnew angle-diff-from-123-to-456
|
|
|
|
3. Reapply patches
|
|
|
|
You may have to skip reapplying certain patches there, for example if they have
|
|
been integrated into ANGLE since our last update. The short patch descriptions above
|
|
in this file should help you make that decision.
|
|
|
|
If you have recorded the individual patch unapply operations in step 1 as separate
|
|
Mercurial patches, this will be easy, just apply the inverse patches now, in reverse
|
|
order:
|
|
|
|
$ patch -p1 -R < .hg/patches/unapply-angle-some-bug-fix.patch
|
|
$ hg status
|
|
# hg add any new ANGLE files under gfx/angle
|
|
$ hg qnew angle-some-bug-fix.patch
|
|
|
|
Note that here you need to proceed in the reverse order of what you did in step 1.
|
|
|
|
4. Update our Makefiles
|
|
|
|
Open your ANGLE diff file (~/angle-diff-from-123-to-456), search for GYP files
|
|
(e.g. build_angle.gyp), it's easy-to-read JSON. It may list additions of new files,
|
|
or removal of old files. You have to reflect this in our Makefiles:
|
|
|
|
gfx/angle/Makefile.in
|
|
gfx/angle/src/libEGL/Makefile.in
|
|
gfx/angle/src/libGLESv2/Makefile.in
|
|
|
|
The first one is our main Makefile. It has basically the ANGLE shader compiler.
|
|
Changes there will typically have to be applied also to the two other Makefiles.
|
|
These two other Makefiles are Windows-only and build the ANGLE GLES2-on-top-of-D3D
|
|
implementation.
|
|
|
|
5. Update patch files
|
|
|
|
Something like:
|
|
|
|
$ cp .hg/patches/angle-some-bug-fix.patch gfx/angle
|
|
|
|
For each patch that you reapplied.
|
|
|
|
If a patch was removed (not reapplied), remove the corresponding patch file.
|
|
|
|
6. Update this README.mozilla
|
|
|
|
You'll have to update at least the ANGLE revision number and probably the patch
|
|
list as well.
|
|
|
|
7. Push to Try
|
|
|
|
Make sure to test both Windows and non-Windows, and enable mochitest-1 in your
|
|
Try options. You may want reftest as well, as we have WebGL reftests.
|
|
|
|
8. Get reviews.
|
|
|
|
Typically, you would get review on your Makefiles patch, and any
|
|
new patches that you need to add to get this update to work.
|
|
|
|
You do not need a review for the ANGLE diff itself and for trivial updates of
|
|
existing patches.
|
|
|
|
|
|
== Visual Studio Solution Files ==
|
|
Ignore these. We don't use them anymore. We use custom Makefiles.
|
|
|
|
|
|
== Generated parser code==
|
|
Don't bother about that anymore. The parser is now generated and included in the ANGLE svn repo.
|