libxl: Generate golang bindings in libxl Makefile

The generated golang bindings (types.gen.go and helpers.gen.go) are
left checked in so that they can be fetched from xenbits using the
golang tooling.  This means that they must be updated whenever
libxl_types.idl (or other dependencies) are updated.  However, the
golang bindings are only built optionally; we can't assume that anyone
updating libxl_types.idl will also descend into the tools/golang tree
to re-generate the bindings.

Fix this by re-generating the golang bindings from the libxl Makefile
when the IDL dependencies are updated, so that anyone who updates
libxl_types.idl will also end up updating the golang generated files
as well.

 - Make a variable for the generated files, and a target in
   xenlight/Makefile which will only re-generate the files.

 - Add a target in libxl/Makefile to call external idl generation
   targets (currently only golang).

For ease of testing, also add a specific target in libxl/Makefile just
to check and update files generated from the IDL.

This does mean that there are two potential paths for generating the
files during a parallel build; but that shouldn't be an issue, since
tools/golang/xenlight should never be built until after tools/libxl
has completed building anyway.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Nick Rosbrook <rosbrookn@ainfosec.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This commit is contained in:
George Dunlap committed 2020-05-28 12:20:53 +01:00
1 parent 724913de8a
commit 60db5da62a
2 files changed
+26 -2

No files matched your search

+10 -1
View File
@@ -17,12 +17,21 @@ all: build
.PHONY: package
package: $(XEN_GOPATH)$(GOXL_PKG_DIR)
$(XEN_GOPATH)/src/$(XEN_GOCODE_URL)/xenlight/: xenlight.go types.gen.go helpers.gen.go
GOXL_GEN_FILES = types.gen.go helpers.gen.go
$(XEN_GOPATH)/src/$(XEN_GOCODE_URL)/xenlight/: xenlight.go $(GOXL_GEN_FILES)
$(INSTALL_DIR) $(XEN_GOPATH)$(GOXL_PKG_DIR)
$(INSTALL_DATA) xenlight.go $(XEN_GOPATH)$(GOXL_PKG_DIR)
$(INSTALL_DATA) types.gen.go $(XEN_GOPATH)$(GOXL_PKG_DIR)
$(INSTALL_DATA) helpers.gen.go $(XEN_GOPATH)$(GOXL_PKG_DIR)
# NOTE: This target is called from libxl/Makefile:all. Since that
# target must finish before golang/Makefile is called, this is
# currently safe. It must not be called from anywhere else in the
# Makefile system without careful thought about races with
# xenlight/Makefile:all
idl-gen: $(GOXL_GEN_FILES)
%.gen.go: gengotypes.py $(LIBXL_SRC_DIR)/libxl_types.idl $(LIBXL_SRC_DIR)/idl.py
XEN_ROOT=$(XEN_ROOT) $(PYTHON) gengotypes.py $(LIBXL_SRC_DIR)/libxl_types.idl
+16 -1
View File
@@ -218,7 +218,7 @@ testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
.PHONY: all
all: $(CLIENTS) $(TEST_PROGS) $(PKG_CONFIG) $(PKG_CONFIG_LOCAL) \
libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
$(AUTOSRCS) $(AUTOINCS)
$(AUTOSRCS) $(AUTOINCS) idl-external
$(LIBXL_OBJS) $(LIBXLU_OBJS) $(SAVE_HELPER_OBJS) \
$(LIBXL_TEST_OBJS) $(TEST_PROG_OBJS): \
@@ -274,6 +274,21 @@ _libxl_type%.h _libxl_type%_json.h _libxl_type%_private.h _libxl_type%.c: libxl_
$(call move-if-changed,__libxl_type$(stem)_json.h,_libxl_type$(stem)_json.h)
$(call move-if-changed,__libxl_type$(stem).c,_libxl_type$(stem).c)
# NOTE: This is safe to do at the moment because idl-external and
# idl-gen are only called from libxl/Makefile:all, which must return
# before golang/Makefile is callid. idl-external and idl-gen must
# never be called from another part of the make system without careful thought
# about races with tools/golang/xenlight/Makefile:all
.PHONY: idl-external
idl-external:
$(MAKE) -C $(XEN_ROOT)/tools/golang/xenlight idl-gen
LIBXL_IDLGEN_FILES = _libxl_types.h _libxl_types_json.h _libxl_types_private.h _libxl_types.c \
_libxl_types_internal.h _libxl_types_internal_json.h _libxl_types_internal_private.h _libxl_types_internal.c
idl-gen: $(LIBXL_GEN_FILES) idl-external
libxenlight.so: libxenlight.so.$(MAJOR)
$(SYMLINK_SHLIB) $< $@
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.