Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Msvc patches #141

Closed
wants to merge 4 commits into from

3 participants

@marvingreenberg

These patches work for me to build swig and the test suite using msvc (cl.exe). I've used VS2012 32 bit and VS2010 64 bit windows (I didn't try all the combinations yet), and I've only run the CSHARP test suite so far, since that was my main goal (testing csharp changes I'm making on the "real" C#/.Net environment). I imagine other test suites will work or fail to differing degrees, but this should be a significant step in supporting Windows development (better?). I built without pcre to prevent needing to building native pcre, although I came close to getting a native build of pcre.

I had earlier tried getting mingw/cygwin builds as described at swig.org, unsuccessfully. In any case, that was not what I wanted since I wanted to actually build using cl/csc. This (to me) is simpler than getting (some old version) mingw installed and configured, if you have the MS compiler. I assume you could also use Visual Studio express but did not try that.

Right now the whole csharp test suite passes on VS2010 W7 x64, except for tests needing the disabled pcre. Interestingly there is a test failure on VS2012 W7 x86, li_std_auto_ptr. System.Exception,: number of objects should be 1. I haven't looked at that.

Here are my instructions to use this patch:

Install cygwin, with automake, autoconf, git, make, byacc, bison. I
initially also installed cygwin gcc/g++ toolchains, which allows
building swig with gcc, and then reconfiguring to run/build the tests
using cl (msvc) (and csc for .Net). But the patch now works to build
swig itself.

Install a boost distribution, just unzip. I installed boost without building
anything - Swig only needs headers, thankfully. There is a twist.
The autotools 'compile' changes all -I<dir> includes to be -I<dir>/include
so you need to unzip it and then move ./boost to ./include/boost. Suggestions?

Source the environment for MSVC toolchain using provided scripts.
Alternatively use visual studio vcvars.bat script somehow before
starting cygwin. I added scripts under Win/ that seem to work.

$ . Win/env-vs2010-64.sh

Configure swig to build and run tests using native MS tool chain
It may be possible to configure/build pcre natively. I came close.

$ ./autogen.sh; ./configure CC='cl' CXX='cl' --with-boost=c:/boost_1_55_0 --without-pcre
$ make && make install 

Run some tests, or run a single tests showing commands

$ make check-csharp-test-suite
$ make check-csharp-test-suite FLAGS= CPP_TEST_CASES=li_std_auto_ptr \
>           C_TEST_CASES= MULTI_CPP_TEST_CASES=
marvingreenberg added some commits
@marvingreenberg marvingreenberg Fixes for swig builds and tests using MSVC
On windows platforms, with paths set up for MSVC toolchains,
this works to build swig and run test suites, assuming
"windows" install of boost.

./autogen.sh;  ./configure CC='cl' CXX='cl' --with-boost=c:/boost_1_55_0 --without-pcre

Also remove -g flag generating annoying swig warnings.
May be some more proper autoconf way to do this.
900cf4d
@marvingreenberg marvingreenberg Add environment scripts to set paths for visual studio compilers 973a541
@vadz

Couldn't we just do

case `uname` in
    CYGWIN*)
        SWIG_LIB=`cygpath -w $srcdir/Lib`
        ;;
esac

here, as usual? It would be slightly less cryptic IMHO.

Depending on what you're trying to do, you could still be configured to use cygwin toolchain gcc/g++, so cannot just hardcode. OTOH, this could just be an autoconf substitution. It's just the last thing I fixed.

@vadz
Owner

I had no idea it was possible to use MSVC with autoconf, and while I do build SWIG with it under Windows, I was using my own (very simple) makefile to do it so far. Being able to do it using the normal configure invocation would be definitely more convenient!

BTW, what problems did you have with PCRE? AFAIR building it with MSVC was straighforward...

@marvingreenberg

@vadz Re: building PCRE I just looked at it, and tried to build using cygwin and ./configure in a similar fashion (as I've done here). I apparently missed the section "Building on non-Unix-like systems" in the Readme, somehow.

@wsfulton
Owner

I've been testing each release of SWIG for at least java, c#, python on Windows using the autotools for the last decade or so. I have a bunch of hacky scripts to get this working which I keep to myself, but would welcome improvements. The main problem is picking up the location of the target languages and I think CMake is the long term solution to this. I use cygwin and cccl when configuring. cccl is a front end to cl that converts gcc command line arguments into something that cl understands. It looks like you have negated the use of that which I am surprised by, so I will try your patch out when I get a moment. I don't recall having problems with boost though, it sounds like the boost detection autoconf script needs fixing.

There is no need for the win-*.sh scripts, I suggest you remove them from the patch. You should instead just open a Visual Studio command prompt and then run cygwin.bat, after which you can run ./configure.

@marvingreenberg

The boost issue is from autoconf 'compile' I suspect autoconf compile needs some love. I didn't look at cccl, and didn't "negate" its use. I'm open to any approach that allows all developers to do windows development, as opposed to various individual developers coming up with hacky individual solutions. This worked for me, and if others find it useful I think bringing it in to master is worth it. For me, for C#, it seems pretty critical to be able to run the test suite using the whole native microsoft toolchain (and for other developers to be able to do so.)

@marvingreenberg

I looked at a couple other target languages, and this doesn't solve the issue of running test suites other than C#. A few minutes trying to get things configured for other target languages using MSVC yielded a variety of issues - each target has different issues getting configured properly on windows. Various target language developers would have to invest significant effort making this patch more generally useful. This patch has limited benefit without this, and that effort is unlikely since CMake is the strategic solution to solve this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Feb 21, 2014
  1. @marvingreenberg

    Fixes for swig builds and tests using MSVC

    marvingreenberg authored
    On windows platforms, with paths set up for MSVC toolchains,
    this works to build swig and run test suites, assuming
    "windows" install of boost.
    
    ./autogen.sh;  ./configure CC='cl' CXX='cl' --with-boost=c:/boost_1_55_0 --without-pcre
    
    Also remove -g flag generating annoying swig warnings.
    May be some more proper autoconf way to do this.
  2. @marvingreenberg
  3. @marvingreenberg
Commits on Feb 24, 2014
  1. @marvingreenberg
This page is out of date. Refresh to see the latest.
Showing with 29 additions and 9 deletions.
  1. +26 −8 configure.ac
  2. +3 −1 preinst-swig.in
View
34 configure.ac
@@ -27,11 +27,20 @@ AH_BOTTOM([
dnl Check for programs that a user requires to build SWIG
AC_PROG_CC
+# When using CL for CC should use it for CXX too
+# AM_PROG_CC_C_O rewrites $CC, so cannot test "$CC" = cl
+MSVC=
+$CC -? 2>&1 | grep -i microsoft >/dev/null && MSVC=yes
AC_PROG_CXX
AC_EXEEXT
AC_OBJEXT
AM_PROG_CC_C_O # Needed for subdir-objects in AUTOMAKE_OPTIONS
-
+# Want CXX to be same rewritten CC
+if test "$MSVC" = yes; then
+CFLAGS=`echo "$CFLAGS" | sed -e 's/-g//'`
+CXXFLAGS=`echo "$CFLAGS" | sed -e 's/-g//'`
+CXX=$CC
+fi
AC_COMPILE_WARNINGS # Increase warning levels
AC_DEFINE_UNQUOTED(SWIG_CXX, ["$CXX"], [Compiler that built SWIG])
@@ -104,11 +113,15 @@ AS_IF([test "x$with_pcre" != xno],
])
+if test "$MSVC" = yes; then
+enable_ccache=
+AC_MSG_NOTICE([Disabling ccache for $CC])
+else
dnl CCache
AC_ARG_ENABLE([ccache], AS_HELP_STRING([--disable-ccache], [disable building and installation of ccache-swig executable (default enabled)]), [enable_ccache=$enableval], [enable_ccache=yes])
AC_MSG_CHECKING([whether to enable ccache-swig])
AC_MSG_RESULT([$enable_ccache])
-
+fi
if test "$enable_ccache" = yes; then
AC_CONFIG_SUBDIRS(CCache)
ENABLE_CCACHE=1
@@ -187,9 +200,10 @@ then
if test "$GCC" = yes; then
LDSHARED="$CC -shared"
else
- if test "cl" = $CC ; then
- # Microsoft Visual C++ (MSVC)
- LDSHARED="$CC -nologo -LD"
+
+ if test "$MSVC" = yes ; then
+ # Microsoft Visual C++ (MSVC). '/' else autotools 'compile' breaks
+ LDSHARED='$(CC) /nologo /LD'
else
# Unknown compiler try gcc approach
LDSHARED="$CC -shared"
@@ -253,9 +267,9 @@ then
if test "$GCC" = yes; then
TRYLINKINGWITHCXX="CXXSHARED= $CXX -shared "
else
- if test "cl" = $CXX ; then
- # Microsoft Visual C++ (MSVC)
- TRYLINKINGWITHCXX="CXXSHARED= $CXX -nologo -LD"
+ if test "$MSVC" = yes ; then
+ # Microsoft Visual C++ (MSVC). '/' else autotools 'compile' breaks
+ TRYLINKINGWITHCXX='CXXSHARED= $(CXX) /nologo /LD'
else
TRYLINKINGWITHCXX="#unknown Windows compiler"
fi
@@ -356,9 +370,13 @@ fi
# libc++ for tests and examples to run under mono. May affect
# other language targets as well - problem is an OSX incompatibility
# between libraries depending on libstdc++ and libc++.
+# MS compiler requires /EHsc for exception support to run tests
CLANGXX=
$CXX -v 2>&1 | grep -i clang >/dev/null && CLANGXX=yes
case $host in
+ *-*-cygwin* |*-*-mingw* ) if test "$MSVC" = "yes";
+ then PLATCXXFLAGS="$PLATCXXFLAGS -EHsc"
+ fi;;
*-*-darwin11* | *-*-darwin12* |*-*-darwin13* ) if test "$CLANGXX" = "yes";
then PLATCXXFLAGS="$PLATCXXFLAGS -stdlib=libc++"
fi;;
View
4 preinst-swig.in
@@ -2,6 +2,8 @@
builddir=`dirname $0`
srcdir=`cd "$builddir" && cd '@srcdir@' && pwd`
SWIG_LIB=$srcdir/Lib
-#SWIG_LIB=`cygpath -w $srcdir/Lib` # For native Windows version of SWIG
+# For native Windows version of SWIG
+"$builddir/swig" -version 2>&1 | \
+ grep -i 'compiled with' | grep -i -e ' cl ' -e ' cl.exe ' && SWIG_LIB=`cygpath -w $srcdir/Lib`
export SWIG_LIB
exec "$builddir/swig" $*
Something went wrong with that request. Please try again.