OpenE2K/rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

auto merge of #11069 : alexcrichton/rust/issue-11067, r=brson

Browse Source 
Turns out libuv's build system doesn't like us telling them that the build
directory is a relative location, as it always spits out a warning about a
circular dependency being dropped. By using an absolute path, turns out the
warnings isn't spit out, who knew?

Closes #11067
This commit is contained in:
bors 2013-12-22 22:36:30 -08:00
commit f71c0dc2cd
2 changed files with 19 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
mk/rt.mk
View File

@ -186,25 +186,34 @@ else
endif endif
LIBUV_NAME_$(1) := $$(call CFG_STATIC_LIB_NAME_$(1),uv) LIBUV_NAME_$(1) := $$(call CFG_STATIC_LIB_NAME_$(1),uv)
LIBUV_LIB_$(1) := $$(RT_OUTPUT_DIR_$(1))/libuv/$$(LIBUV_NAME_$(1)) LIBUV_DIR_$(1) := $$(RT_OUTPUT_DIR_$(1))/libuv
LIBUV_LIB_$(1) := $$(LIBUV_DIR_$(1))/$$(LIBUV_NAME_$(1))
LIBUV_MAKEFILE_$(1) := $$(CFG_BUILD_DIR)$$(RT_OUTPUT_DIR_$(1))/libuv/Makefile LIBUV_MAKEFILE_$(1) := $$(CFG_BUILD_DIR)$$(RT_OUTPUT_DIR_$(1))/libuv/Makefile
LIBUV_STAMP_$(1) = $$(LIBUV_DIR_$(1))/libuv-auto-clean-stamp
$$(LIBUV_STAMP_$(1)): $(S)src/rt/libuv-auto-clean-trigger
$$(Q)rm -rf $$(LIBUV_DIR_$(1))
$$(Q)mkdir -p $$(@D)
touch $$@
# libuv triggers a few warnings on some platforms # libuv triggers a few warnings on some platforms
LIBUV_CFLAGS_$(1) := $(subst -Werror,,$(CFG_GCCISH_CFLAGS_$(1))) LIBUV_CFLAGS_$(1) := $(subst -Werror,,$(CFG_GCCISH_CFLAGS_$(1)))
$$(LIBUV_MAKEFILE_$(1)): $$(LIBUV_DEPS) $$(LIBUV_MAKEFILE_$(1)): $$(LIBUV_DEPS) $$(MKFILE_DEPS) $$(LIBUV_STAMP_$(1))
(cd $(S)src/libuv/ && \ (cd $(S)src/libuv/ && \
$$(CFG_PYTHON) ./gyp_uv.py -f make -Dtarget_arch=$$(LIBUV_ARCH_$(1)) \ $$(CFG_PYTHON) ./gyp_uv.py -f make -Dtarget_arch=$$(LIBUV_ARCH_$(1)) \
-D ninja \ -D ninja \
-DOS=$$(LIBUV_OSTYPE_$(1)) \ -DOS=$$(LIBUV_OSTYPE_$(1)) \
-Goutput_dir=$$(@D) --generator-output $$(@D)) -Goutput_dir=$$(@D) --generator-output $$(@D))
touch $$@
# Windows has a completely different build system for libuv because of mingw. In # Windows has a completely different build system for libuv because of mingw. In
# theory when we support msvc then we should be using gyp's msvc output instead # theory when we support msvc then we should be using gyp's msvc output instead
# of mingw's makefile for windows # of mingw's makefile for windows
ifdef CFG_WINDOWSY_$(1) ifdef CFG_WINDOWSY_$(1)
$$(LIBUV_LIB_$(1)): $$(LIBUV_DEPS) $$(LIBUV_LIB_$(1)): $$(LIBUV_DEPS) $$(MKFILE_DEPS)
$$(Q)$$(MAKE) -C $$(S)src/libuv -f Makefile.mingw \ $$(Q)$$(MAKE) -C $$(S)src/libuv -f Makefile.mingw \
LDFLAGS="$$(CFG_GCCISH_LINK_FLAGS_$(1))" \ LDFLAGS="$$(CFG_GCCISH_LINK_FLAGS_$(1))" \
CC="$$(CC_$(1)) $$(LIBUV_CFLAGS_$(1)) $$(SNAP_DEFINES)" \ CC="$$(CC_$(1)) $$(LIBUV_CFLAGS_$(1)) $$(SNAP_DEFINES)" \
@ -213,15 +222,17 @@ $$(LIBUV_LIB_$(1)): $$(LIBUV_DEPS)
V=$$(VERBOSE) V=$$(VERBOSE)
$$(Q)cp $$(S)src/libuv/libuv.a $$@ $$(Q)cp $$(S)src/libuv/libuv.a $$@
else else
$$(LIBUV_LIB_$(1)): $$(LIBUV_DEPS) $$(LIBUV_MAKEFILE_$(1)) $$(LIBUV_LIB_$(1)): $$(LIBUV_DIR_$(1))/Release/libuv.a $$(MKFILE_DEPS)
$$(Q)$$(MAKE) -C $$(@D) \ $$(Q)ln -f $$< $$@
$$(LIBUV_DIR_$(1))/Release/libuv.a: $$(LIBUV_DEPS) $$(LIBUV_MAKEFILE_$(1)) \
$$(MKFILE_DEPS)
$$(Q)$$(MAKE) -C $$(LIBUV_DIR_$(1)) \
CFLAGS="$$(LIBUV_CFLAGS_$(1)) $$(SNAP_DEFINES)" \ CFLAGS="$$(LIBUV_CFLAGS_$(1)) $$(SNAP_DEFINES)" \
LDFLAGS="$$(CFG_GCCISH_LINK_FLAGS_$(1))" \ LDFLAGS="$$(CFG_GCCISH_LINK_FLAGS_$(1))" \
CC="$$(CC_$(1))" \ CC="$$(CC_$(1))" \
CXX="$$(CXX_$(1))" \ CXX="$$(CXX_$(1))" \
AR="$$(AR_$(1))" \ AR="$$(AR_$(1))" \
$$(LIBUV_ARGS_$(1)) \ $$(LIBUV_ARGS_$(1)) \
builddir="." \
BUILDTYPE=Release \ BUILDTYPE=Release \
NO_LOAD="$$(LIBUV_NO_LOAD)" \ NO_LOAD="$$(LIBUV_NO_LOAD)" \
V=$$(VERBOSE) V=$$(VERBOSE)

2
src/rt/libuv-auto-clean-trigger Normal file
View File

@ -0,0 +1,2 @@
# Change the contents of this file to force a full rebuild of libuv
2013-12-23