[M3commit] [modula3/cm3] 8bd4b6: Add support for VS2015.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/modula3/cm3
  Commit: 8bd4b698efb42a65b99a8220e645970f3ba36e25
      https://github.com/modula3/cm3/commit/8bd4b698efb42a65b99a8220e645970f3ba36e25
  Author: Jay Krell <jay.krell at cornell.edu>
  Date:   2016-01-02 (Sat, 02 Jan 2016)

  Changed paths:
    A m3-libs/LibcCompat/src/LibcCompat.i3
    A m3-libs/LibcCompat/src/LibcCompat.m3
    A m3-libs/LibcCompat/src/LibcCompatC.c
    A m3-libs/LibcCompat/src/m3makefile
    M m3-libs/sysutils/src/m3makefile
    M m3-sys/cminstall/src/config-no-install/NT.common
    M m3-sys/mklib/src/Main.m3
    M m3-tools/m3bundle/src/m3makefile
    A scripts/env/vs2015/x86.cmd
    M scripts/pkginfo.txt
    M scripts/python/pylib.py
    M scripts/python/upgrade.py

  Log Message:
  -----------
  Add support for VS2015.

 Specifics:

 Upgrade from 5.2.6 successful:
   set CM3_VS2015_OR_NEWER=1 (env\vs2015\x86)
   rmdir /q/s \cm3.2
   xcopy /fivery \cm3-5.2.6 \cm3.2
   path=\cm3.2\bin;%PATH%
   make-dist-cfg.py  (for NT.common update -- note that current config files
                go out of their way to be compatible with older releases)
   upgrade-full.cmd

 The user must set CM3_VS2015_OR_NEWER=1 in the environment.

 Previously and for many years, the C runtime was linked
 to by linking to either libcmt.lib or msvcrt.lib. Chose one
 and only one. (Ignoring the aberrant single threaded libc.lib.)

 With VS2015 this has changed.

 The user must now pick between two sets of libraries.
 For dynamic linking: msvcrt.lib, vcruntime.lib, ucrt.lib.
 For static linking: libcmt.lib, libvcruntime.lib, libucrt.lib.

 This list is derived from:
  echo int main() { return 0; } > 1.c
  cl 1.c /link /verbose
  cl /MD 1.c /link /verbose

 So, this is firstly, a makefile/config change, to link to the extra libraries.
 There might be a way to automatically decide to do this, but I haven't
  yet thought of a good way.

 So the user must set in the environment: CM3_VS2015_OR_NEWER=1.
 This is used in NT.common.
 User might also need to update his config/NT.common with the checked in one.

 As well, the new runtime changes the ABI.
 For example, previously you would statically link to _printf
 or dynamically link to *__imp__printf.

 _printf is now an inline function, so not linkable to unless you
 actually #include the current stdio.h.

 Manual declarations in C or Modula-3 do not work. Nor do using
 .objs/.libs compiled with old headers -- such as m3core.lib.sa.

 So, secondly, package LibcCompat is added to workaround around this.
 This is only needed for bootstrapping -- this is not a new dependency
 foisted everywhere into the system. It is only needed by packages
 built in the bootstrap phase that statically link against the old m3core/libm3.

 Anything built with a current m3core/libm3 with the same toolset as used to build
 themselves will automatically work. But bootstrapping with old static m3core/libm3 will not.

 In future we should consider exporting whatever is our C runtime use from m3core.dll,
 AND never statically linking to m3core.dll. That would remove this problem.
 Neither of these are easy however.

 Thirdly, our mklib is in the business of chosing symbols to export.
 The new large amount of inline code in the C runtime headers introduces new
 symbols for mklib to consider. Mklib also truncates symbols at '@'.
 So even if the new symbols should be exported, mklib breaks them.
 This causes a link error related to ?_OptionsStorage.

 So, thirdly, in mklib, omit any C++ symbols -- symbols that start "?".

 This in particular omits the "_OptionsStorage" global variable introduced by stdio.h (corecrt_stdio_config.h).
 (Again -- consider eliminating C runtime dependency, or exporting it from m3core.
 The problem with eliminating it is, at a minimum, we need exception handling, either
 in the form of setjmp/longjmp, or C++ exception handling, or SEH).

 Upgrading from newer releases than 5.2.6 may very well likely require more workarounds.
 Cross builds should be considered, though the automation there is presently less used
 and might offer other problems to be fixed.

 The addition of a new package that cm3 is dependent on is somewhat disruptive.
 LibcCompat.c can be copied around as needed to remove this inconvenience.
 However, the addition of sysutils a few years ago is an analogous precedent.