mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
f1578d37dc
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 16:58:59 -06:00
# x86_64-pc-windows-msvc configuration
mk: Add support for i686-pc-windows-msvc This commit modifies the configure script and our makefiles to support building 32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can produce a 32-bit or 64-bit binary. The configure script was updated to export more variables at configure time, and the makefiles were rejiggered to selectively reexport the relevant environment variables for the applicable targets they're going to run for.
2015-06-25 17:30:00 -05:00
CC_x86_64-pc-windows-msvc="$(CFG_MSVC_CL_x86_64)" -nologo
LINK_x86_64-pc-windows-msvc="$(CFG_MSVC_LINK_x86_64)" -nologo
CXX_x86_64-pc-windows-msvc="$(CFG_MSVC_CL_x86_64)" -nologo
CPP_x86_64-pc-windows-msvc="$(CFG_MSVC_CL_x86_64)" -nologo
AR_x86_64-pc-windows-msvc="$(CFG_MSVC_LIB_x86_64)" -nologo
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 16:58:59 -06: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 15:50:56 -05: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 16:58:59 -06:00
CFG_LIB_DSYM_GLOB_x86_64-pc-windows-msvc=$(1)-*.dylib.dSYM
Scale back changes made
2015-05-08 16:44:17 -05:00
CFG_JEMALLOC_CFLAGS_x86_64-pc-windows-msvc :=
mk: Compile C code on MSVC with /MD On MSVC there are two ways that the CRT can be linked, either statically or dynamically. Each object file produced by the compiler is compiled against msvcrt (a dll) or libcmt (a static library). When the linker is dealing with more than one object file, it requires that all object files link to the same CRT, or else the linker will spit out some errors. For now, compile code with `-MD` as it seems to appear more often in C libraries so we'll stick with the same trend.
2015-06-03 17:24:35 -05:00
CFG_GCCISH_CFLAGS_x86_64-pc-windows-msvc := -MD
CFG_GCCISH_CXXFLAGS_x86_64-pc-windows-msvc := -MD
Scale back changes made
2015-05-08 16:44:17 -05: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 16:58:59 -06: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 15:59:51 -05: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 12:57:41 -06: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