mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
rust/mk/cfg/x86_64-pc-windows-msvc.mk

29 lines
1.3 KiB
Makefile
Raw Normal View History

Very hacky MSVC hacks. Conflicts: mk/platform.mk src/librustc/session/config.rs src/librustc_back/target/aarch64_apple_ios.rs src/librustc_back/target/aarch64_linux_android.rs src/librustc_back/target/arm_linux_androideabi.rs src/librustc_back/target/arm_unknown_linux_gnueabi.rs src/librustc_back/target/arm_unknown_linux_gnueabihf.rs src/librustc_back/target/armv7_apple_ios.rs src/librustc_back/target/armv7s_apple_ios.rs src/librustc_back/target/i386_apple_ios.rs src/librustc_back/target/i686_apple_darwin.rs src/librustc_back/target/i686_pc_windows_gnu.rs src/librustc_back/target/i686_unknown_dragonfly.rs src/librustc_back/target/i686_unknown_linux_gnu.rs src/librustc_back/target/mips_unknown_linux_gnu.rs src/librustc_back/target/mipsel_unknown_linux_gnu.rs src/librustc_back/target/mod.rs src/librustc_back/target/powerpc_unknown_linux_gnu.rs src/librustc_back/target/x86_64_apple_darwin.rs src/librustc_back/target/x86_64_apple_ios.rs src/librustc_back/target/x86_64_pc_windows_gnu.rs src/librustc_back/target/x86_64_unknown_dragonfly.rs src/librustc_back/target/x86_64_unknown_freebsd.rs src/librustc_back/target/x86_64_unknown_linux_gnu.rs src/librustc_back/target/x86_64_unknown_openbsd.rs src/librustc_llvm/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/trans/base.rs src/libstd/os.rs src/rustllvm/RustWrapper.cpp
2015-03-04 22:58:59 +00:00
# x86_64-pc-windows-msvc configuration
test: Move run-make tests into compiletest Forcing them to be embedded in makefiles precludes being able to run them in rustbuild, and adding them to compiletest gives us a great way to leverage future enhancements to our "all encompassing test suite runner" as well as just moving more things into Rust. All tests are still Makefile-based in the sense that they rely on `make` being available to run them, but there's no longer any Makefile-trickery to run them and rustbuild can now run them out of the box as well.
2016-04-14 15:51:03 -07:00
CC_x86_64-pc-windows-msvc=$(CFG_MSVC_CL_x86_64)
LINK_x86_64-pc-windows-msvc=$(CFG_MSVC_LINK_x86_64)
CXX_x86_64-pc-windows-msvc=$(CFG_MSVC_CL_x86_64)
CPP_x86_64-pc-windows-msvc=$(CFG_MSVC_CL_x86_64)
AR_x86_64-pc-windows-msvc=$(CFG_MSVC_LIB_x86_64)
Very hacky MSVC hacks. Conflicts: mk/platform.mk src/librustc/session/config.rs src/librustc_back/target/aarch64_apple_ios.rs src/librustc_back/target/aarch64_linux_android.rs src/librustc_back/target/arm_linux_androideabi.rs src/librustc_back/target/arm_unknown_linux_gnueabi.rs src/librustc_back/target/arm_unknown_linux_gnueabihf.rs src/librustc_back/target/armv7_apple_ios.rs src/librustc_back/target/armv7s_apple_ios.rs src/librustc_back/target/i386_apple_ios.rs src/librustc_back/target/i686_apple_darwin.rs src/librustc_back/target/i686_pc_windows_gnu.rs src/librustc_back/target/i686_unknown_dragonfly.rs src/librustc_back/target/i686_unknown_linux_gnu.rs src/librustc_back/target/mips_unknown_linux_gnu.rs src/librustc_back/target/mipsel_unknown_linux_gnu.rs src/librustc_back/target/mod.rs src/librustc_back/target/powerpc_unknown_linux_gnu.rs src/librustc_back/target/x86_64_apple_darwin.rs src/librustc_back/target/x86_64_apple_ios.rs src/librustc_back/target/x86_64_pc_windows_gnu.rs src/librustc_back/target/x86_64_unknown_dragonfly.rs src/librustc_back/target/x86_64_unknown_freebsd.rs src/librustc_back/target/x86_64_unknown_linux_gnu.rs src/librustc_back/target/x86_64_unknown_openbsd.rs src/librustc_llvm/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/trans/base.rs src/libstd/os.rs src/rustllvm/RustWrapper.cpp
2015-03-04 22:58:59 +00:00
CFG_LIB_NAME_x86_64-pc-windows-msvc=$(1).dll
CFG_STATIC_LIB_NAME_x86_64-pc-windows-msvc=$(1).lib
mk: Tweak the LIB_GLOB for MSVC Right now the distribution tarball for MSVC only includes the *.dll files for the supporting libraries, but not the corresponding *.lib files which allow actually linking to the dll. This means that the current MSVC nightlies cannot produce dynamically linked binaries as the *.lib files are not available to link against. This commit modifies the `LIB_GLOB` used to copy the files around to include the `lib` variant of the `dll`.
2015-06-11 13:50:56 -07:00
CFG_LIB_GLOB_x86_64-pc-windows-msvc=$(1)-*.{dll,lib}
Very hacky MSVC hacks. Conflicts: mk/platform.mk src/librustc/session/config.rs src/librustc_back/target/aarch64_apple_ios.rs src/librustc_back/target/aarch64_linux_android.rs src/librustc_back/target/arm_linux_androideabi.rs src/librustc_back/target/arm_unknown_linux_gnueabi.rs src/librustc_back/target/arm_unknown_linux_gnueabihf.rs src/librustc_back/target/armv7_apple_ios.rs src/librustc_back/target/armv7s_apple_ios.rs src/librustc_back/target/i386_apple_ios.rs src/librustc_back/target/i686_apple_darwin.rs src/librustc_back/target/i686_pc_windows_gnu.rs src/librustc_back/target/i686_unknown_dragonfly.rs src/librustc_back/target/i686_unknown_linux_gnu.rs src/librustc_back/target/mips_unknown_linux_gnu.rs src/librustc_back/target/mipsel_unknown_linux_gnu.rs src/librustc_back/target/mod.rs src/librustc_back/target/powerpc_unknown_linux_gnu.rs src/librustc_back/target/x86_64_apple_darwin.rs src/librustc_back/target/x86_64_apple_ios.rs src/librustc_back/target/x86_64_pc_windows_gnu.rs src/librustc_back/target/x86_64_unknown_dragonfly.rs src/librustc_back/target/x86_64_unknown_freebsd.rs src/librustc_back/target/x86_64_unknown_linux_gnu.rs src/librustc_back/target/x86_64_unknown_openbsd.rs src/librustc_llvm/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/trans/base.rs src/libstd/os.rs src/rustllvm/RustWrapper.cpp
2015-03-04 22:58:59 +00:00
CFG_LIB_DSYM_GLOB_x86_64-pc-windows-msvc=$(1)-*.dylib.dSYM
Scale back changes made
2015-05-08 14:44:17 -07:00
CFG_JEMALLOC_CFLAGS_x86_64-pc-windows-msvc :=
test: Move run-make tests into compiletest Forcing them to be embedded in makefiles precludes being able to run them in rustbuild, and adding them to compiletest gives us a great way to leverage future enhancements to our "all encompassing test suite runner" as well as just moving more things into Rust. All tests are still Makefile-based in the sense that they rely on `make` being available to run them, but there's no longer any Makefile-trickery to run them and rustbuild can now run them out of the box as well.
2016-04-14 15:51:03 -07:00
CFG_GCCISH_CFLAGS_x86_64-pc-windows-msvc := -MD -nologo
CFG_GCCISH_CXXFLAGS_x86_64-pc-windows-msvc := -MD -nologo
Scale back changes made
2015-05-08 14:44:17 -07:00
CFG_GCCISH_LINK_FLAGS_x86_64-pc-windows-msvc :=
Very hacky MSVC hacks. Conflicts: mk/platform.mk src/librustc/session/config.rs src/librustc_back/target/aarch64_apple_ios.rs src/librustc_back/target/aarch64_linux_android.rs src/librustc_back/target/arm_linux_androideabi.rs src/librustc_back/target/arm_unknown_linux_gnueabi.rs src/librustc_back/target/arm_unknown_linux_gnueabihf.rs src/librustc_back/target/armv7_apple_ios.rs src/librustc_back/target/armv7s_apple_ios.rs src/librustc_back/target/i386_apple_ios.rs src/librustc_back/target/i686_apple_darwin.rs src/librustc_back/target/i686_pc_windows_gnu.rs src/librustc_back/target/i686_unknown_dragonfly.rs src/librustc_back/target/i686_unknown_linux_gnu.rs src/librustc_back/target/mips_unknown_linux_gnu.rs src/librustc_back/target/mipsel_unknown_linux_gnu.rs src/librustc_back/target/mod.rs src/librustc_back/target/powerpc_unknown_linux_gnu.rs src/librustc_back/target/x86_64_apple_darwin.rs src/librustc_back/target/x86_64_apple_ios.rs src/librustc_back/target/x86_64_pc_windows_gnu.rs src/librustc_back/target/x86_64_unknown_dragonfly.rs src/librustc_back/target/x86_64_unknown_freebsd.rs src/librustc_back/target/x86_64_unknown_linux_gnu.rs src/librustc_back/target/x86_64_unknown_openbsd.rs src/librustc_llvm/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/trans/base.rs src/libstd/os.rs src/rustllvm/RustWrapper.cpp
2015-03-04 22:58:59 +00:00
CFG_GCCISH_DEF_FLAG_x86_64-pc-windows-msvc :=
CFG_LLC_FLAGS_x86_64-pc-windows-msvc :=
CFG_INSTALL_NAME_x86_64-pc-windows-msvc =
CFG_EXE_SUFFIX_x86_64-pc-windows-msvc := .exe
CFG_WINDOWSY_x86_64-pc-windows-msvc := 1
CFG_UNIXY_x86_64-pc-windows-msvc :=
CFG_LDPATH_x86_64-pc-windows-msvc :=
CFG_RUN_x86_64-pc-windows-msvc=$(2)
CFG_RUN_TARG_x86_64-pc-windows-msvc=$(call CFG_RUN_x86_64-pc-windows-msvc,,$(2))
configure: Start adding MSVC support This commit starts to add MSVC support to the ./configure script to enable the build system to detect and build an MSVC target with the cl.exe compiler and toolchain. The primary change here is a large sanity check when an MSVC target is requested (and currently only `x86_64-pc-windows-msvc` is recognized). When building an MSVC target, the configure script either requires the `--msvc-root` argument or for `cl.exe` to be in `PATH`. It also requires that if in the path `cl.exe` is the 64-bit version of the compiler. Once detected the configure script will run the `vcvarsall.bat` script provided by Visual Studio to learn about the `INCLUDE` and `LIB` variables needed by the `cl.exe` compiler to run (the default include/lib paths for the compiler/linker). These variables are then reexported when running `make` to ensure that our own compiles are running the same toolchain. The purpose of this detection and environment variable scraping is to avoid requiring the build itself to be run inside of a `cmd.exe` shell but rather allow it to run in the currently expected MinGW/MSYS shell.
2015-05-11 13:59:51 -07:00
CFG_GNU_TRIPLE_x86_64-pc-windows-msvc := x86_64-pc-win32
mk: Move disable-jemalloc logic into makefiles The `--disable-jemalloc` configure option has a failure mode where it will create a distribution that is not compatible with other compilers. For example the nightly for Linux will assume that it will link to jemalloc by default as an allocator for executable crates. If, however, a standard library is used which was built via `./configure --disable-jemalloc` then this will fail because the jemalloc crate wasn't built. While this seems somewhat reasonable as a niche situation, the same mechanism is used for disabling jemalloc for platforms that just don't support it. For example if the rumprun target is compiled then the sibiling Linux target *also* doesn't have jemalloc. This is currently a problem for our cross-build nightlies which build many targets. If rumprun is also built, it will disable jemalloc for all targets, which isn't desired. This commit moves the platform-specific disabling of jemalloc as hardcoded logic into the makefiles that is scoped per-platform. This way when configuring multiple targets **without the `--disable-jemalloc` option specified** all targets will get jemalloc as they should.
2016-02-08 10:57:41 -08:00
# Currently the build system is not configured to build jemalloc
# with MSVC, so we omit this optional dependency.
CFG_DISABLE_JEMALLOC_x86_64-pc-windows-msvc := 1
Reference in New Issue Copy Permalink