Because of the way the SDK and Android system images are branched,
host code that goes into the SDK tools can't live in the same
repository as code that goes into the system image. This change keeps
the emugl host code in sdk.git/emulator/opengl while moving the emugl
system code to development.git/tools/emulator/opengl.
A few changes were made beyond simply cloning the directories:
(a) Makefiles were modified to only build the relevant components. Not
doing so would break the build due to having multiple rule
definitions.
(b) Protocol spec files were moved from the guest encoder directories
to the host decoder directories. The decoder must support older
versions of the protocol, but not newer versions, so it makes
sense to keep the latest version of the protocol spec with the
decoder.
(c) Along with that, the encoder is now built from checked in
generated encoder source rather than directly from the protocol
spec. The generated code must be updated manually. This makes it
possible to freeze the system encoder version without freezing the
host decoder version, and also makes it very obvious when a
protocol changes is happening that will require special
backwards-compatibility support in the decoder/renderer.
(d) Host-only and system-only code were removed from the repository
where they aren't used.
(e) README and DESIGN documents were updated to reflect this split.
No actual source code was changed due to the above.
Change-Id: I2c936101ea0405b372750d36ba0f01e84d719c43
The emulator GLES support has two interfaces: a host shared library
interface used by QEMU, and a protocol between the platform and the
host. The host library interface is not versioned; QEMU and the GLES
renderer must match. The protocol on the other hand must be backwards
compatible: a new GLES renderer must support an older platform image.
Thus for branching purposes it makes more sense to put the GLES
renderer in sdk.git, which is branched along with qemu.git for SDK
releases. Platform images will be built against the protocol version
in the platform branch of sdk.git.
Change-Id: Ie73fce12815c9740e27d0f56caa53c6ceb3d30cc
It is possible to move the final installation path of a shared
library by using LOCAL_MODULE_PATH/LOCAL_UNSTRIPPED_PATH in its
module declaration.
We do this for example to put certain libraries under /system/lib/egl
or /system/lib/hw.
However, the Android build system has a small bug where you cannot
depend on these shared libraries because it will complain it doesn't
find them under /system/lib, the default install location.
More precisely, consider libfoo defined as:
include $(CLEAR_VARS)
LOCAL_MODULE := libfoo
LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/egl
...
include $(BUILD_SHARED_LIBRARY)
Its final binary will be installed to /system/lib/egl/libfoo.so
Now, let's write a module that depends on it, as:
include $(CLEAR_VARS)
LOCAL_MODULE := libbar
LOCAL_SHARED_LIBRARIES += libfoo
...
include $(BUILD_SHARED_LIBRARY)
The build system will complain there is no rule to define the target
/system/lib/libfoo.so, but the target should be /system/lib/egl/libfoo.so.
A work-around is to define libbar as follows instead:
include $(CLEAR_VARS)
LOCAL_MODULE := libbar
LOCAL_ADDITIONAL_DEPENDENCIES := $(TARGET_OUT_SHARED_LIBRARIES)/egl/libfoo.so
...
include $(BUILD_SHARED_LIBRARY)
This works if you don't need to link against the library when building your
shared library (which is fortunately the case for the GLES emulation
libraries).
That's essentially what this patch implements under common.mk. We update
emugl-set-shared-library-subpath to record that a module has been "moved",
and we avoid adding them to the LOCAL_SHARED_LIBRARIES variable of the
modules that export it.
+ Simplify three Android.mk files accordingly.
Change-Id: Id15bef5359b0daa8d82bfaa5abf9346f00190ab5
Added GLESv2 library to system.
Made fixes to the host libOpenGLRender to
compile and support GLESv2 (defined WITH_GLES2).
Other fixes required to make GLESv2 to work.
Change-Id: I9eb198e6092e7fa3550342c50929dd1714282cb3
This patch is a major rework of the build opengl-emulation
build scripts. See README for details.
In a nutshell, this introduces various functions that considerably
simplify the declaration of the 26+ modules in this implementation,
by handling auto-generation of sources and module imports/exports.
Change-Id: I827522d783c7b6cf5eafd37204a1025c235458cd
