wine/gecko
0
0
Fork 0
mirror of https://gitlab.winehq.org/wine/wine-gecko.git synced 2024-09-13 09:24:08 -07:00
Code Issues Packages Projects Releases Wiki Activity
6cb0048f56
gecko/dom/bindings/Makefile.in

126 lines
3.2 KiB
Makefile
Raw Normal View History

Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
# This Source Code Form is subject to the terms of the Mozilla Public
Bug 737006 - Use internal ply only if needed. r=khuey
2012-04-06 11:06:52 -07:00
# License, v. 2.0. If a copy of the MPL was not distributed with this file,
# You can obtain one at http://mozilla.org/MPL/2.0/.
Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
DEPTH = ../..
topsrcdir = @top_srcdir@
srcdir = @srcdir@
VPATH = @srcdir@
MODULE = dom
LIBRARY_NAME = dombindings_s
LIBXUL_LIBRARY = 1
FORCE_STATIC_LIB = 1
EXPORT_LIBRARY = 1
include $(topsrcdir)/config/config.mk
# Define USE_JSOP_ACCESSORS to a nonempty string like "yes" to use them
USE_JSOP_ACCESSORS =
ifdef USE_JSOP_ACCESSORS
DEFINES += -DUSE_JSOP_ACCESSORS
ACCESSOR_OPT = --use-jsop-accessors
else
ACCESSOR_OPT =
endif
# Need this to find all our DOM source files.
include $(topsrcdir)/dom/dom-config.mk
include $(topsrcdir)/dom/webidl/WebIDL.mk
Bug 742217. Reduce the use of nested namespaces in our binding code. r=peterv,bent In the new setup, all per-interface DOM binding files are exported into mozilla/dom. General files not specific to an interface are also exported into mozilla/dom. In terms of namespaces, most things now live in mozilla::dom. Each interface Foo that has generated code has a mozilla::dom::FooBinding namespace for said generated code (and possibly a mozilla::bindings::FooBinding_workers if there's separate codegen for workers). IDL enums are a bit weird: since the name of the enum and the names of its entries all end up in the same namespace, we still generate a C++ namespace with the name of the IDL enum type with "Values" appended to it, with a ::valuelist inside for the actual C++ enum. We then typedef EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to refer to the values, but means that values from different enums don't collide with each other. The enums with the proto and constructor IDs in them now live under the mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively. Again, this lets us deal sanely with the whole "enum value names are flattened into the namespace the enum is in" deal. The main benefit of this setup (and the reason "Binding" got appended to the per-interface namespaces) is that this way "using mozilla::dom" should Just Work for consumers and still allow C++ code to sanely use the IDL interface names for concrete classes, which is fairly desirable. --HG-- rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
2012-05-02 21:35:38 -07:00
binding_include_path := mozilla/dom
Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
binding_header_files := $(subst .webidl,Binding.h,$(webidl_files))
binding_cpp_files := $(subst .webidl,Binding.cpp,$(webidl_files))
globalgen_targets := \
PrototypeList.h \
Bug 742217. Reduce the use of nested namespaces in our binding code. r=peterv,bent In the new setup, all per-interface DOM binding files are exported into mozilla/dom. General files not specific to an interface are also exported into mozilla/dom. In terms of namespaces, most things now live in mozilla::dom. Each interface Foo that has generated code has a mozilla::dom::FooBinding namespace for said generated code (and possibly a mozilla::bindings::FooBinding_workers if there's separate codegen for workers). IDL enums are a bit weird: since the name of the enum and the names of its entries all end up in the same namespace, we still generate a C++ namespace with the name of the IDL enum type with "Values" appended to it, with a ::valuelist inside for the actual C++ enum. We then typedef EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to refer to the values, but means that values from different enums don't collide with each other. The enums with the proto and constructor IDs in them now live under the mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively. Again, this lets us deal sanely with the whole "enum value names are flattened into the namespace the enum is in" deal. The main benefit of this setup (and the reason "Binding" got appended to the per-interface namespaces) is that this way "using mozilla::dom" should Just Work for consumers and still allow C++ code to sanely use the IDL interface names for concrete classes, which is fairly desirable. --HG-- rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
2012-05-02 21:35:38 -07:00
RegisterBindings.h \
RegisterBindings.cpp \
Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
$(NULL)
CPPSRCS = \
$(binding_cpp_files) \
$(filter %.cpp, $(globalgen_targets)) \
Bug 742217. Reduce the use of nested namespaces in our binding code. r=peterv,bent In the new setup, all per-interface DOM binding files are exported into mozilla/dom. General files not specific to an interface are also exported into mozilla/dom. In terms of namespaces, most things now live in mozilla::dom. Each interface Foo that has generated code has a mozilla::dom::FooBinding namespace for said generated code (and possibly a mozilla::bindings::FooBinding_workers if there's separate codegen for workers). IDL enums are a bit weird: since the name of the enum and the names of its entries all end up in the same namespace, we still generate a C++ namespace with the name of the IDL enum type with "Values" appended to it, with a ::valuelist inside for the actual C++ enum. We then typedef EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to refer to the values, but means that values from different enums don't collide with each other. The enums with the proto and constructor IDs in them now live under the mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively. Again, this lets us deal sanely with the whole "enum value names are flattened into the namespace the enum is in" deal. The main benefit of this setup (and the reason "Binding" got appended to the per-interface namespaces) is that this way "using mozilla::dom" should Just Work for consumers and still allow C++ code to sanely use the IDL interface names for concrete classes, which is fairly desirable. --HG-- rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
2012-05-02 21:35:38 -07:00
BindingUtils.cpp \
Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
$(NULL)
EXPORTS_NAMESPACES = $(binding_include_path)
EXPORTS_$(binding_include_path) = \
DOMJSClass.h \
PrototypeList.h \
Bug 742217. Reduce the use of nested namespaces in our binding code. r=peterv,bent In the new setup, all per-interface DOM binding files are exported into mozilla/dom. General files not specific to an interface are also exported into mozilla/dom. In terms of namespaces, most things now live in mozilla::dom. Each interface Foo that has generated code has a mozilla::dom::FooBinding namespace for said generated code (and possibly a mozilla::bindings::FooBinding_workers if there's separate codegen for workers). IDL enums are a bit weird: since the name of the enum and the names of its entries all end up in the same namespace, we still generate a C++ namespace with the name of the IDL enum type with "Values" appended to it, with a ::valuelist inside for the actual C++ enum. We then typedef EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to refer to the values, but means that values from different enums don't collide with each other. The enums with the proto and constructor IDs in them now live under the mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively. Again, this lets us deal sanely with the whole "enum value names are flattened into the namespace the enum is in" deal. The main benefit of this setup (and the reason "Binding" got appended to the per-interface namespaces) is that this way "using mozilla::dom" should Just Work for consumers and still allow C++ code to sanely use the IDL interface names for concrete classes, which is fairly desirable. --HG-- rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
2012-05-02 21:35:38 -07:00
RegisterBindings.h \
Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
Nullable.h \
Bug 742217. Reduce the use of nested namespaces in our binding code. r=peterv,bent In the new setup, all per-interface DOM binding files are exported into mozilla/dom. General files not specific to an interface are also exported into mozilla/dom. In terms of namespaces, most things now live in mozilla::dom. Each interface Foo that has generated code has a mozilla::dom::FooBinding namespace for said generated code (and possibly a mozilla::bindings::FooBinding_workers if there's separate codegen for workers). IDL enums are a bit weird: since the name of the enum and the names of its entries all end up in the same namespace, we still generate a C++ namespace with the name of the IDL enum type with "Values" appended to it, with a ::valuelist inside for the actual C++ enum. We then typedef EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to refer to the values, but means that values from different enums don't collide with each other. The enums with the proto and constructor IDs in them now live under the mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively. Again, this lets us deal sanely with the whole "enum value names are flattened into the namespace the enum is in" deal. The main benefit of this setup (and the reason "Binding" got appended to the per-interface namespaces) is that this way "using mozilla::dom" should Just Work for consumers and still allow C++ code to sanely use the IDL interface names for concrete classes, which is fairly desirable. --HG-- rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
2012-05-02 21:35:38 -07:00
BindingUtils.h \
Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
$(binding_header_files) \
$(NULL)
LOCAL_INCLUDES += -I$(topsrcdir)/js/xpconnect/src \
-I$(topsrcdir)/js/xpconnect/wrappers
TEST_DIRS += test
include $(topsrcdir)/config/rules.mk
bindinggen_dependencies := \
BindingGen.py \
Bindings.conf \
Configuration.py \
Codegen.py \
ParserResults.pkl \
$(GLOBAL_DEPS) \
$(NULL)
$(binding_header_files): %Binding.h: $(bindinggen_dependencies) \
$(webidl_base)/%.webidl \
$(NULL)
Bug 741125: Update WebIDL parser.
2012-04-12 15:14:10 -07:00
PYTHONDONTWRITEBYTECODE=1 $(PYTHON) $(topsrcdir)/config/pythonpath.py \
Bug 737006 - Use internal ply only if needed. r=khuey
2012-04-06 11:06:52 -07:00
$(PLY_INCLUDE) -I$(srcdir)/parser \
$(srcdir)/BindingGen.py $(ACCESSOR_OPT) header \
$(srcdir)/Bindings.conf $*Binding \
$(webidl_base)/$*.webidl
Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
$(binding_cpp_files): %Binding.cpp: $(bindinggen_dependencies) \
$(webidl_base)/%.webidl \
$(NULL)
Bug 741125: Update WebIDL parser.
2012-04-12 15:14:10 -07:00
PYTHONDONTWRITEBYTECODE=1 $(PYTHON) $(topsrcdir)/config/pythonpath.py \
Bug 737006 - Use internal ply only if needed. r=khuey
2012-04-06 11:06:52 -07:00
$(PLY_INCLUDE) -I$(srcdir)/parser \
$(srcdir)/BindingGen.py $(ACCESSOR_OPT) cpp \
$(srcdir)/Bindings.conf $*Binding \
$(webidl_base)/$*.webidl
Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
$(globalgen_targets): ParserResults.pkl
CACHE_DIR = _cache
globalgen_dependencies := \
GlobalGen.py \
Bindings.conf \
Configuration.py \
Codegen.py \
$(CACHE_DIR)/.done \
$(GLOBAL_DEPS) \
$(NULL)
$(CACHE_DIR)/.done:
$(MKDIR) -p $(CACHE_DIR)
@$(TOUCH) $@
ParserResults.pkl: $(globalgen_dependencies) \
$(addprefix $(webidl_base)/, $(webidl_files))
Bug 741125: Update WebIDL parser.
2012-04-12 15:14:10 -07:00
PYTHONDONTWRITEBYTECODE=1 $(PYTHON) $(topsrcdir)/config/pythonpath.py \
Bug 737006 - Use internal ply only if needed. r=khuey
2012-04-06 11:06:52 -07:00
$(PLY_INCLUDE) -I$(srcdir)/parser \
Fix for bug 740069 (Generate JS bindings in C++ with a python script for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug. --HG-- rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
2012-03-30 21:42:20 -07:00
$(srcdir)/GlobalGen.py $(ACCESSOR_OPT) $(srcdir)/Bindings.conf $(webidl_base) \
--cachedir=$(CACHE_DIR) \
$(webidl_files)
GARBAGE += \
$(binding_header_files) \
$(binding_cpp_files) \
$(globalgen_targets) \
ParserResults.pkl \
webidlyacc.py \
parser.out \
$(NULL)
Reference in New Issue Copy Permalink